Shulou(Shulou.com)06/01 Report--

Editor to share with you how to use temporary containers for troubleshooting in Kubernetes, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's learn about it!

Preface

The container and the ecosystem around it have changed the way engineers deploy, maintain, and troubleshoot workloads. However, debugging applications on a Kubernetes cluster can sometimes be difficult because you may not find the debugging tools you need in the container. Many engineers use stripped-down, release-based builds of base images without distributions, not even a package manager or shell. Even some teams use scratch as the base image and add only the files needed for the application to run. Some of the reasons for this common practice are:

Has a smaller attack area.

To get faster scanning performance.

Reduces the size of the mirror.

For faster builds and shorter CD/CI cycles.

Reduce dependencies.

These streamlined base images do not include tools for troubleshooting applications or their dependencies. This is the greatest use of the Kubernetes temporary container function. Temporary containers allow you to create container images that contain all debugging tools you might need. Once you need to debug, you can deploy the temporary container to the running Pod of your choice.

We cannot add containers to deployed containers; you need to update spec and recreate resources. However, you can add temporary containers to an existing Pod to troubleshoot online problems.

This article describes how to use temporary containers to troubleshoot workloads on Kubernetes.

What is a temporary container?

Temporary containers differ from other containers in that they lack guarantees of resources or execution and never restart automatically, so they are not suitable for building applications. Temporary containers are described using the same ContainerSpec section as regular containers, but many fields are incompatible and not allowed.

Temporary containers do not have port configuration, so fields such as ports,livenessProbe,readinessProbe are not allowed.

Pod resource allocation is immutable, so resources configuration is not allowed.

For a complete list of allowed fields, see the EphemeralContainer reference documentation.

Temporary containers are created using a special ephemeralcontainers processor in API, rather than being added directly to the pod.spec segment, so you cannot use kubectl edit to add a temporary container.

As with regular containers, temporary containers cannot be changed or deleted after they are added to Pod.

Configuration of temporary containers

Temporary containers share the same spec as regular containers. However, some fields are disabled and some behaviors are changed. Some major changes are listed below; check the temporary container specification for a complete list.

They won't restart.

Resources are not allowed to be defined.

Port is not allowed.

Startup, activity, and ready probes are not allowed.

Start the temporary container

First, check to see if the temporary container feature is enabled.

Kubectl debug-it-- image=busybox

If this feature is not enabled, you will see a message similar to the following.

Defaulting debug container name to debugger-wg54p.

Error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").

After appending EphemeralContainers=true to-- feature-gates= in the parameters kubelet, kube-apiserver, kube-controller-manager, kube-proxy, kube-scheduler, for example:

...-- feature-gates=RemoveSelfLink=false,EphemeralContainers=true... Use temporary containers

Now that the cluster supports temporary containers, let's give it a try. To create a temporary container, use the debug subcommand of the kubectl command line tool. First, create a Deployment

Kubectl create deployment nginx-deployment-image=nginx

Get the name of the Pod that requires debug

$kubectl get podsNAME READY STATUS RESTARTS AGEnginx-deployment-66b6c48dd5-frsv9 1 move 1 Running 6 62d

The following command creates a new temporary container in pod nginx-deployment-66b6c48dd5-frsv9. The image of the temporary container is busybox. The-I and-t parameters allow us to attach to the newly created container.

$kubectl debug-it pods/nginx-deployment-66b6c48dd5-frsv9-image=busybox

Now we can debug.

/ # ping 8.8.8.8PING 8.8.8.8 (8.8.8.8): 56 data bytes64 bytes from 8.8.8.8: seq=0 ttl=112 time=9.797 ms64 bytes from 8.8.8.8: seq=1 ttl=112 time=9.809 Ms ^ C / # nc-- helpBusyBox v1.34.1 (2021-11-11 01:55:05 UTC) multi-call binary.Usage: nc [OPTIONS] HOST PORT-connectnc [OPTIONS]-l-p PORT [HOST] [PORT]-listen...

When you use the kubectl describe pod command, you can see a new field "Ephemeral Containers" that contains the temporary container and its properties.

$kubectl describe pods .Ephemeral Containers: debugger-thwrn: Container ID: containerd://eec23aa9ee63d96b82970bb947b29cbacc30685bbc3418ba840dee109f871bf0 Image: busybox Image ID: docker.io/library/busybox@sha256:e7157b6d7ebbe2cce5eaa8cfe8aa4fa82d173999b9f90a9ec42e57323546c353 Port: Host Port: share the process namespace with the temporary container

Process namespace sharing has always been a good troubleshooting option, and this feature can be used for temporary containers. Process namespace sharing cannot be applied to an existing container, so a copy of the target container must be created. -- share-processesflag enables process namespace sharing when used with-- copy-to. These flags copy the existing Pod spec definition to the new definition and enable process namespace sharing in spec.

$kubectl debug- it-image=busybox-share-processes-copy-to=debug-pod

Run the ps command to see which processes are running. As you would expect, you can see the / pause in the busybox container and the nginx process in the nginx-deployment container.

# ps auxPID USER TIME COMMAND 1 root 0:00 / pause 6 root 0:00 nginx: master process nginx-g daemon off; 11 0:00 nginx: worker process 12 root 0:00 sh 17 root 0:00 ps aux

Using the process namespace, the shared container file system is also accessible, which is useful for debugging. You can access the container using the / proc//root link. From the output above, we know that the PID of nginx is 6.

# ls / proc/6/root/etc/nginxconf.d koi-utf mime.types nginx.conf uwsgi_params fastcgi_params koi-win modules scgi_params win-utf

Here, we can see the Nginx directory structure and configuration files on the target container.

These are all the contents of the article "how to use temporary containers for troubleshooting in Kubernetes". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.