Group items tagged

sudo netplan apply

sudo netplan apply

The upgrade procedure on control plane nodes should be executed one node at a time.

Manually upgrade your CNI provider plugin.

sudo systemctl daemon-reload sudo systemctl restart kubelet

If kubeadm upgrade fails and does not roll back, for example because of an unexpected shutdown during execution, you can run kubeadm upgrade again.

To recover from a bad state, you can also run kubeadm upgrade apply --force without changing the version that your cluster is running.

kubeadm-backup-etcd contains a backup of the local etcd member data for this control plane Node.

the contents of this folder can be manually restored in /var/lib/etcd

kubeadm-backup-manifests contains a backup of the static Pod manifest files for this control plane Node.

the contents of this folder can be manually restored in /etc/kubernetes/manifests

Enforces the version skew policies.

Upgrades the control plane components or rollbacks if any of them fails to come up.

CMD instruction should be used to run the software contained by your image, along with any arguments

CMD should be given an interactive shell (bash, python, perl, etc)

COPY them individually, rather than all at once

COPY is preferred

using ADD to fetch packages from remote URLs is strongly discouraged

always use COPY

The best use for ENTRYPOINT is to set the image's main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).

the image name can double as a reference to the binary as shown in the command above

ENTRYPOINT instruction can also be used in combination with a helper script

The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container.

use USER to change to a non-root user

avoid installing or using sudo

avoid switching USER back and forth frequently.

always use absolute paths for your WORKDIR

ONBUILD is only useful for images that are going to be built FROM a given image

The “onbuild” image will fail catastrophically if the new build's context is missing the resource being added.

When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers.

Inadvertently including files that are not necessary for building an image results in a larger build context and larger image size.

To exclude files not relevant to the build (without restructuring your source repository) use a .dockerignore file. This file supports exclusion patterns similar to .gitignore files.

minimize image layers by leveraging build cache.

avoid installing extra or unnecessary packages just because they might be “nice to have.”

Decoupling applications into multiple containers makes it easier to scale horizontally and reuse containers

Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.

do multi-stage builds and only copy the artifacts you need into the final image. This allows you to include tools and debug information in your intermediate build stages without increasing the size of the final image.

avoid duplication of packages and make the list much easier to update.

When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified.

simply comparing the instruction in the Dockerfile with one of the child images is sufficient.

For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file.

If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.

In that case just the command string itself is used to find a match.

Whenever possible, use current official repositories as the basis for your images.

Using RUN apt-get update && apt-get install -y ensures your Dockerfile installs the latest package versions with no further coding or manual intervention.

cache busting

Docker executes these commands using the /bin/sh -c interpreter, which only evaluates the exit code of the last operation in the pipe to determine success.

set -o pipefail && to ensure that an unexpected error prevents the build from inadvertently succeeding.

The CMD instruction should be used to run the software contained by your image, along with any arguments.

CMD should rarely be used in the manner of CMD [“param”, “param”] in conjunction with ENTRYPOINT

The ENV instruction is also useful for providing required environment variables specific to services you wish to containerize,

COPY only supports the basic copying of local files into the container

the best use for ADD is local tar file auto-extraction into the image, as in ADD rootfs.tar.xz /

using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead

The best use for ENTRYPOINT is to set the image’s main command, allowing that image to be run as though it was that command (and then use CMD as the default flags).

the image name can double as a reference to the binary as shown in the command

The VOLUME instruction should be used to expose any database storage area, configuration storage, or files/folders created by your docker container.

use VOLUME for any mutable and/or user-serviceable parts of your image

If you absolutely need functionality similar to sudo, such as initializing the daemon as root but running it as non-root), consider using “gosu”.

always use absolute paths for your WORKDIR

An ONBUILD command executes after the current Dockerfile build completes.

Think of the ONBUILD command as an instruction the parent Dockerfile gives to the child Dockerfile

Be careful when putting ADD or COPY in ONBUILD. The “onbuild” image fails catastrophically if the new build’s context is missing the resource being added.

Rootless mode does not use binaries with SETUID bits or file capabilities, except newuidmap and newgidmap, which are needed to allow multiple UIDs/GIDs to be used in the user namespace.

expose privileged ports (< 1024)

add net.ipv4.ip_unprivileged_port_start=0 to /etc/sysctl.conf (or /etc/sysctl.d) and run sudo sysctl --system

dockerd-rootless.sh uses slirp4netns (if installed) or VPNKit as the network stack by default.

This error occurs when the number of available entries in /etc/subuid or /etc/subgid is not sufficient.

This error occurs mostly when the host is running in cgroup v2. See the section Fedora 31 or later for information on switching the host to use cgroup v1.

--net=host doesn’t listen ports on the host network namespace This is an expected behavior, as the daemon is namespaced inside RootlessKit’s network namespace. Use docker run -p instead.

Make sure that the br_netfilter module is loaded.

you should ensure net.bridge.bridge-nf-call-iptables is set to 1 in your sysctl config,

kubeadm will not install or manage kubelet or kubectl for you, so you will need to ensure they match the version of the Kubernetes control plane you want kubeadm to install for you.

one minor version skew between the kubelet and the control plane is supported, but the kubelet version may never exceed the API server version.

Both the container runtime and the kubelet have a property called "cgroup driver", which is important for the management of cgroups on Linux machines.