曾几何时，咱们将本人的利用运行在Kubernetes上，每当呈现容器异样解体时，咱们往往都是一边重启容器，一边面对解体的容器无从下手。通常在业务研发本人build的镜像内蕴含了shell，咱们还能通过在command中嵌入一个["sleep", "3600"]命令来阻塞容器内服务启动，不过也有时候会呈现不晓得从哪里冒出来一个distroless镜像，这时可能最先解体的就是运维了。那是一种运维这个职业自诞生以来，第一次感触到不知所措并脱离掌控的无助感。于是在k8s环境下无奈debug容器的梗开始在坊间广为吐槽。

第一个突破魔咒的是kubectl-debug，它蕴含了agent和debug-tools两个局部。也是目前全网内搜到文档最全的解决方案。不过目前它的开发仿佛曾经进行，上一次提交还是在8个月之前，而最近一次Release版本也停留在两年前。更难以承受的是，以后它无奈被集成在容器运行时为Containerd的k8s集群。

只管kubectl-debug已经的确是一款十分好用的容器调试工具，但现在Kubernetes曾经有了更好的容器调试解决方案，Ephemeral Containers。

Ephemeral Containers

Ephemeral Containers字如其名，它就是一个长期容器。这是一个自Kubernetes v1.16中作为alpha引入的新性能，尽管以后它还没有GA，不过自从在Kubernetes v1.18之后，在kubectl内曾经集成了debug客户端，咱们简直能够残缺的应用并体验它的新个性。

长期容器的指标是为Kubernetes用户提供一个故障诊断工具，同时具备满足以下需要：

  • 作为一个开箱即用的平台化工具
  • 不依赖于曾经蕴含在容器镜像中的工具
  • 不须要间接登陆计算节点(能够通过Kubernetes API的治理拜访Node)

不过也有货色是长期容器不打算反对的，比方对windows上启用长期容器就不太敌对。

启用长期容器的个性也非常简单，在kubernetes v1.16之后的版本中将启动参数--feature-gates=EphemeralContainers=true配置到kube-api和kubelet服务上重启即可。

在1.20之前，kubectl debug工具被放在alpha中，留神不同版本的命令操作差异
这里举荐应用客户端为1.20+的版本体验会更好

那么咱们有了Ephemeral Containers能做哪些事件呢？

1. POD Troubleshooting

如上文所说，咱们能够间接通过kubectl debug命令进行容器调试。最间接简略的对一个pod进行调试命令如下：

kubectl debug mypod -it --image=busybox

默认状况下用户不指定长期容器名称的话，debug容器名称就由kubectl主动生成一个惟一id的名称。如果用户须要本人指定容器名称则应用

kubectl debug mypod -c debugger --image=busybox

有了长期容器除了日常debug性能外，咱们能够扩大出很多新花样的玩法。比方批量跑某个命名空间下的平安扫描的脚本而不必烦扰原容器。

for pod in $(kubectl get -o name pod); do    kubectl debug --image security/pod_scanner -p $pod /sanner.shdone

2. POD Troubleshooting by Copy

对于没有开启Ephemeral Containers个性的集群，咱们就只能通过复制模式来调试容器。它的原理是复制一个指定pod的新容器，并将debug作为sidecar追随新容器一起启动。通过这种形式也能达到曲线救国的目标。此种形式的几个参数还是挺有意思：

--copy-to   指定新pod的名称--replace=true   是否删除原容器--same-node=true  是否调度到和原容器一样的node上--share-processes=true  是否共享容器pid空间

例如咱们就能够启动一个跟须要调试pod一样配置的debug容器如下：

kubectl debug mypod -it \--container=debug \--image=busybox \--copy-to=my-debugger \--same-node=true \--share-processes=true

3. Node Troubleshooting

对！你没看错！利用Ephemeral Containers还能对Worker节点进行调试。当以节点为指标调用时，kubectl debug 将创立一个带有node名称的pod，并且调度到该节点。同时该容器还具备了hostIPC、hostNetwork和hostPID这些特权模式。不堪设想的是Worker节点的根文件系统还被mount到了debug容器下的/host目录下。

间接执行这个命令就能debug主机。

kubectl debug node/mynode -it --image=busybox

Debug镜像

工欲善其事，必先利其器。不管怎样咱们都须要一套工具欠缺的debug镜像，在解决问题时可能得心应手。尽管网上也有不少debug镜像，不过都还是不如本人构建来的畅快。

这里小白分享一个Debug镜像的Dockerfile，大家能够依据本人条件批改即可。

FROM golang:alpine as grpcurlRUN apk update \  && apk add --virtual build-dependencies git \  && apk add bash curl jq \  && go get -u github.com/fullstorydev/grpcurl \  && go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latestFROM alpine:latestRUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories && \    apk update && \    apk add --no-cache vim bash tcpdump curl wget strace mysql-client iproute2 redis jq iftop tzdata tar nmap bind-tools htop && \    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeRUN wget -O /usr/bin/httpstat https://github.com/davecheney/httpstat/releases/download/v1.0.0/httpstat-linux-amd64-v1.0.0 && \    chmod +x /usr/bin/httpstatCOPY --from=grpcurl  /go/bin/grpcurl /usr/bin/grpcurlENV TZ=Asia/Shanghai LC_ALL=C.UTF-8 LANG=C.UTF-8 LANGUAGE=C.UTF-8ENTRYPOINT [ "/bin/bash" ]

debug镜像内反对的工具包如下图

总结

本文次要讲述了kubernetes在v1.18版本之后被提上alpha的Ephemeral Containers个性，通过长期容器咱们能够debug容器，甚至还能够debug主机。它的确是一个十分不便和足以代替kubectl-debug的解决方案。不过，目前长期容器对于用户权限这块并没有特地的阐明，特地是用特权模式调试主机的时候，心愿前面可能借助PSP（Pod Security Policy）做一个额定的补充。

关注公众号【云原生小白】，回复「入群」退出Loki学习群