the error about adding slave to master - kubernetes

building a master localy.
I am trying to use /kubernetes/docs/getting-started-guides/docker-multinode/master.sh
master is done!
some detail imformation:
K8S_VERSION is set to: 1.2.4
ETCD_VERSION is set to: 2.2.1
FLANNEL_VERSION is set to: 0.5.5
FLANNEL_IFACE is set to: wlan0
FLANNEL_IPMASQ is set to: true
MASTER_IP is set to: 192.168.1.104
ARCH is set to: amd64
Detecting your OS distro ...
Starting bootstrap docker ...
Starting k8s ...
4fa730ca61727c165345885639cbef4d5a34b5d0fa3a361c13b0abc3ead0dd58
{ "Network": "10.1.0.0/16", "Backend": {"Type": "vxlan"}}
vDOCKER_OPTS="$DOCKER_OPTS --mtu=1450 --bip=10.1.48.1/24"
next add a vagrant virtualbox slave to master.
trying to use /kubernetes/docs/getting-started-guides/docker-multinode/worker.sh it bring some issue:
K8S_VERSION is set to: 1.2.4
FLANNEL_VERSION is set to: 0.5.5
FLANNEL_IFACE is set to: wlan0
FLANNEL_IPMASQ is set to: true
MASTER_IP is set to: 192.168.1.104
ARCH is set to: amd64
Detecting your OS distro ...
Starting bootstrap docker ...
Starting k8s ...
Error response from daemon: lstat /var/lib/docker-bootstrap/aufs/mnt/8881a46cdd1fe51b7f0f86e8659bc8f9c905089b0d86a273e85d134
c637041c1/tmp/flannel/subnet.env: no such file or directory
I have two vm,
one is on public_network:192.168.1.110
other is on private_network:192.168.50.2
all is the same error output.
ps: can I use the worker.sh in aws ec2?
question is a bit miscellaneous,
hoping a cattle help me to consolidation.

I am lucky enough to pass the work node, but I don't know the exactly reason.
now I package the vagrant box in my google cloud disk, url is below----[https://drive.google.com/file/d/0B9WzutmgDDrodkpLRGM2c0J1RXc/view?usp=sharing][1].
before you take a public or private network with it, you should download a pre-compiled kubernetes version, and copy it to the vagrant folder.
use vagrant init kube-slave to start.

Related

bitbake error in do_rootfs: systemd depends on update-rc.d

I got a bit stuck debugging a yocto build problem. I encountered this while updating from yocto warrior (2.7) to yocto dunfell (3.1) The build fails during the building of the rootfs, all steps before seem to work:
ERROR: my-project-develop-1.0-r0 do_rootfs: Could not invoke dnf. Command '/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/etc/yum.repos.d --installroot=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs --setopt=logdir=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/temp --repofrompath=oe-repo,/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/oe-rootfs-repo --nogpgcheck install base-version-develop bash cairo cantarell-fonts cellular-geolocation commit-hashes-develop crda curl disable-airplane-mode disable-power-saving-for-some-devices disconnect-wifi-without-connectivity dnsmasq dosfstools e2fsprogs e2fsprogs-resize2fs firmware-develop fit-conf gbs-overlay geofencing-db hostapd htop i2c-tools iw jq lateswap libgpiod libgpiod-tools linux-firmware-rtl8192cu matlab-develop modemmanager mosquitto mosquitto-clients nano network-configuration networkmanager openmoji-fonts os-release ostree ostree-devicetrees ostree-initramfs ostree-kernel packagegroup-base packagegroup-base-extended packagegroup-core-boot packagegroup-core-ssh-openssh parted psplash-raspberrypi pstree raspi-gpio rtwpriv run-postinsts set-modes-and-bands source-han-sans-jp-fonts special-shadow sqlite3tzdata u-boot-fw-utils userland weston weston-init wifi-configurator-frontend-develop wifilm811 wifilm843 wpa-supplicant locale-base-en-us' returned 1:
DNF version: 4.2.2
cachedir: /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Tue 16 Feb 2021 08:59:38 AM UTC.
No module defaults found
--> Starting dependency resolution
--> Finished dependency resolution
Error:
Problem 1: package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
Problem 2: package packagegroup-distro-base-1.0-r83.raspberrypi_cm3 requires packagegroup-core-boot, but none of the providers can be installed
- package packagegroup-base-1.0-r83.raspberrypi_cm3 requires packagegroup-distro-base, but none of the providers can be installed
- package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
Problem 3: package packagegroup-base-1.0-r83.raspberrypi_cm3 requires packagegroup-distro-base, but none of the providers can be installed
- package packagegroup-distro-base-1.0-r83.raspberrypi_cm3 requires packagegroup-core-boot, but none of the providers can be installed
- package packagegroup-base-extended-1.0-r83.raspberrypi_cm3 requires packagegroup-base, but none of the providers can be installed
- package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
It seems that systemd-1:244.5 depends on update-rc.d. This doesn't make a lot sense to me, since I don't need those scripts anymore when using systemd - maybe there are for some compatibility reasons? Puzzled by this I checked the reference and it seems that I have the right settings to use systemd exclusively:
$ bitbake -e exos-develop | grep "^DISTRO_FEATURES"
DISTRO_FEATURES="acl alsa argp bluetooth ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat largefile opengl ptest multiarch wayland vulkan systemd weston wayland sota usrmerge systemd systemd pulseaudio gobject-introspection-data ldconfig"
DISTRO_FEATURES_BACKFILL="pulseaudio sysvinit gobject-introspection-data ldconfig"
DISTRO_FEATURES_BACKFILL_CONSIDERED="sysvinit sysvinit"
DISTRO_FEATURES_DEFAULT="acl alsa argp bluetooth ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat"
DISTRO_FEATURES_FILTER_NATIVE="api-documentation"
DISTRO_FEATURES_FILTER_NATIVESDK="api-documentation"
DISTRO_FEATURES_NATIVE="x11 ipv6 xattr sota"
DISTRO_FEATURES_NATIVESDK="x11"
During debugging I also saw that poky's systemd recipe uses the update-rc.d.bbclass. From what I can see it only gets active when the DISTRO_FEATURES contain sysvinit, which is apparently not the case here. Maybe some caching issue?
Any ideas how I can debug this further?
I found it out myself (interesting how asking questions helps you thinking...):
The issue was in the systemd recipe itself and related to the systemd-compat-units recipe. I was able to fix it with this in my layer's recipes-core/systemd/systemd_%.bbappend:
# Disable all relations to update-rc.d:
PACKAGECONFIG_remove = "sysvinit"
RRECOMMENDS_${PN}_remove = "systemd-compat-units"
I'm still wondering how this issue came to be at all, though.
Would be great if somebody could explain why this happened at all.

Starting Codeready Container with libvirt cause "format of backing image was not specified in the image metadata"

I'm trying to use CRC for testing Openshift 4 on my laptop (Ubuntu 20). CRC version 1.17 doesn't support Virtualbox virtualizazion so following the setup instructions
https://access.redhat.com/documentation/en-us/red_hat_codeready_containers/1.17/html/getting_started_guide/installation_gsg
i'm using libvirt, but when i start the cluster with crc start it launch following error
INFO Checking if oc binary is cached
INFO Checking if podman remote binary is cached
INFO Checking if goodhosts binary is cached
INFO Checking minimum RAM requirements
INFO Checking if running as non-root
INFO Checking if Virtualization is enabled
INFO Checking if KVM is enabled
INFO Checking if libvirt is installed
INFO Checking if user is part of libvirt group
INFO Checking if libvirt daemon is running
INFO Checking if a supported libvirt version is installed
INFO Checking if crc-driver-libvirt is installed
INFO Checking if libvirt 'crc' network is available
INFO Checking if libvirt 'crc' network is active
INFO Checking if NetworkManager is installed
INFO Checking if NetworkManager service is running
INFO Checking if /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf exists
INFO Checking if /etc/NetworkManager/dnsmasq.d/crc.conf exists
INFO Starting CodeReady Containers VM for OpenShift 4.5.14...
ERRO Error starting stopped VM: virError(Code=55, Domain=18, Message='Requested operation is not valid: format of backing image '/home/claudiomerli/.crc/cache/crc_libvirt_4.5.14/crc.qcow2' of image '/home/claudiomerli/.crc/machines/crc/crc.qcow2' was not specified in the image metadata (See https://libvirt.org/kbase/backing_chains.html for troubleshooting)')
Error starting stopped VM: virError(Code=55, Domain=18, Message='Requested operation is not valid: format of backing image '/home/claudiomerli/.crc/cache/crc_libvirt_4.5.14/crc.qcow2' of image '/home/claudiomerli/.crc/machines/crc/crc.qcow2' was not specified in the image metadata (See https://libvirt.org/kbase/backing_chains.html for troubleshooting)')
I have not experiences with libvirt so i'm stuck on that and online i'm not finding anything...
Thanks
There is an issue with the crc_libvirt_4.5.14 image. The easiest way to fix it is to do a
qemu-img rebase -f qcow2 -F qcow2 -b /home/${USER}/.crc/cache/crc_libvirt_4.5.14/crc.qcow2 /home/${USER}/.crc/machines/crc/crc.qcow2
Now, if you try to do a crc start, you going to face a "Permission denied" error, which is related to Apparmor, unless you whitelisted your home directory. If you don't want to hack around with Apparmor settings, the /var/lib/libvirt/images supposed to be whitelisted. Move the image to there:
sudo mv /home/${USER}/.crc/machines/crc/crc.qcow2 /var/lib/libvirt/images
then edit the virtual machine settings pointing to the new image location: virsh edit crc , then replace the <source file='/home/yourusername/.crc/machines/crc/crc.qcow2'/> to <source file='/var/lib/libvirt/images/crc.qcow2'/>.
Then do the crc start and... that's it.
The relevant Github issues to follow:
https://github.com/code-ready/crc/issues/1596
https://github.com/code-ready/crc/issues/1578

Failed to infer CIDR network for mon ip

I follow the instructions to bootstrap a new Ceph (I'm new to Ceph) cluster.
I got the following error:
sudo cephadm bootstrap --mon-ip <mon-ip>
INFO:cephadm:Verifying podman|docker is present...
INFO:cephadm:Verifying lvm2 is present...
INFO:cephadm:Verifying time synchronization is in place...
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Repeating the final host check...
INFO:cephadm:podman|docker (/usr/bin/podman) is present
INFO:cephadm:systemctl is present
INFO:cephadm:lvcreate is present
INFO:cephadm:Unit systemd-timesyncd.service is enabled and running
INFO:cephadm:Host looks OK
INFO:root:Cluster fsid: e08484be-72c1-11ea-a13e-0050563f093a
INFO:cephadm:Verifying IP *<mon-ip>* port 3300 ...
INFO:cephadm:Verifying IP *<mon-ip>* port 6789 ...
ERROR: Failed to infer CIDR network for mon ip *<mon-ip>*; pass --skip-mon-network to configure it later
What does it mean ? How to fix it ?
cephadm is still fairly new. I've tracked a few days ago in:
https://tracker.ceph.com/issues/44828
Please run
ceph config set mon public_network <mon_network>
after bootstrap finished.
Is this the exact command you ran?
sudo cephadm bootstrap --mon-ip *<mon-ip>*
If so you actually need to replace *<mon-ip>* with the actual IP address that you want the monitor daemon to listen on.
For future reference, on that page, any command you see that has a variable surrounded by asterisks is something you would need to replace with an address/host/hostname etc. that applies to your environment.

Bazel Kubernetes Object Error: no objects passed to apply (Google Container Registry)

I have a k8s_object rule to apply a deployment to my Google Kubernetes Cluster. Here is my setup:
load("#io_bazel_rules_docker//nodejs:image.bzl", "nodejs_image")
nodejs_image(
name = "image",
data = [":lib", "//:package.json"],
entry_point = ":index.ts",
)
load("#io_bazel_rules_k8s//k8s:object.bzl", "k8s_object")
k8s_object(
name = "k8s_deployment",
template = ":gateway.deployment.yaml",
kind = "deployment",
cluster = "gke_cents-ideas_europe-west3-b_cents-ideas",
images = {
"gcr.io/cents-ideas/gateway:latest": ":image"
},
)
But when I run bazel run //services/gateway:k8s_deployment.apply, I get the following error
INFO: Analyzed target //services/gateway:k8s_deployment.apply (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //services/gateway:k8s_deployment.apply up-to-date:
bazel-bin/services/gateway/k8s_deployment.apply
INFO: Elapsed time: 0.113s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
$ /snap/bin/kubectl --kubeconfig= --cluster=gke_cents-ideas_europe-west3-b_cents-ideas --context= --user= apply -f -
2020/02/12 14:52:44 Unable to publish images: unable to publish image gcr.io/cents-ideas/gateway:latest
error: no objects passed to apply
error: no objects passed to apply
It doesn't push the new image to the Google Container Registry.
Strangely, this worked a few days ago. But I didn't change anything.
Here is the full code if you need to take a closer look: https://github.com/flolude/cents-ideas/blob/069c773ade88dfa8aff492f024a1ade1f8ed282e/services/gateway/BUILD
Update
I don't know if this has something to do with this issue but when I run
gcloud auth configure-docker
I get some warnings:
WARNING: `docker-credential-gcloud` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
WARNING: Your config file at [/home/flolu/.docker/config.json] contains these credential helper entries:
{
"credHelpers": {
"asia.gcr.io": "gcloud",
"staging-k8s.gcr.io": "gcloud",
"us.gcr.io": "gcloud",
"gcr.io": "gcloud",
"marketplace.gcr.io": "gcloud",
"eu.gcr.io": "gcloud"
}
}
Adding credentials for all GCR repositories.
WARNING: A long list of credential helpers may cause delays running 'docker build'. We recommend passing the registry name to configure only the registry you are using.
gcloud credential helpers already registered correctly.
I had google-cloud-sdk installed via snap install. What I did to make it work is to remove google-cloud-sdk via
snap remove google-cloud-sdk
and then followed those instructions to install it via
sudo apt install google-cloud-sdk
Now it works fine

During start of Docker I get this message: "getting the final child's pid from pipe caused "read init-p: connection reset by peer"

I have Docker installed under CentOS Linux 7.6.1810 and Plesk Onyx 17.8.11, and everything was fine. For a few hours I can't start mongoDB or Docker anymore.
I get this error message
{"message":"OCI runtime create failed: container_linux.go:344: starting container process caused \"process_linux.go:297: getting the final child's pid from pipe caused \\\"read init-p: connection reset by peer\\\"\": unknown"}
What could it be?
I have fixed it, I downgraded containerd.io to the version 1.2.0 and Docker is running.
Docker-ce 18.09.2 + Linux Kernel 3.10.0 produces the same problem as you. If we want to use Docker-ce 18.09.2, Linux Kernel 4.x+ is required.