接上一篇《如何像专业人士一样调试 Kubernetes 应用程序错误(一)》。继续我们的调试之旅,我们继续创建部署定义:
arduino
kubectl create deploy nginx --image=nginx --dry-run=client -o yaml > deploy-nginx-course.yaml -- sleep 23132

使用"kubectl run"命令和" --- dry-run"选项,我们可以预览并将yaml定义导出到文件。此外,为了避免忘记如何在kubernetes中启动命令,我作为参数发送了一个命令,这给了我在容器中复制和粘贴的定义。之后,我们可以打开导出的yaml文件并在其中添加sidecar。sidecar可以包含一个"sleep"命令来允许容器运行。
我们打开文件"deploy-nginx-course.yaml",并向其中添加sidecar:
vi deploy-nginx-course.yaml

在此过程中,我们添加了一个带有Ubuntu的sidecar容器和一个暂停容器的命令。编辑并保存YAML文件后,我们将其应用到Kubernetes,确保成功创建了部署和pods。
arduino
kubectl apply -f deploy-nginx-course.yamlkubectl get deploy && kubectl get pod

部署pod后,我们检查pod中的容器的状态。如果应用程序没有准备好,我们再次检查日志。但是,如果应用程序准备好了并且没有重新启动,我们可以进入Ubuntu容器。
bash
kubectl exec -it POD-NAME -c CONTAINER-NAME COMMAND

通常,我使用Alpine或Ubuntu镜像,因为它带有"sh"和"bash"这样的shell命令。这帮助我们访问容器,而不需要检查其他图像的任何Entrypoints。访问Ubuntu容器后,我们安装curl命令来检查Nginx是否正确运行。
apt updateapt install curl netcat -ycurl localhostnc -v localhost 80

如果应用程序似乎运行正常,我们需要确保问题不在容器本身。我们可以通过测试Nginx是否在pod外部可用来检查这一点。为此,我们在与应用程序相同的命名空间中创建一个新的容器。
arduino
kubectl run alpine --image=alpine -- sleep 231312

接下来,我们创建一个Alpine pod并从容器中移除sidecar。然后,我们复制Nginx pod的IP并安装curl命令来测试它。
arduino
kubectl get pod -o wide

sql
kubectl exec -it alpine shapk add curlcurl POD-IP

我们还使用"pod-ip-address.my-namespace.pod.cluster-domain.example"这个DNS名进行测试。

我还建议您在应用程序所在的不同命名空间中使用相同的pod启动相同的测试。如果发生了故障,您需要检查以下解决方案:
我们还建议在应用程序所在的另一个命名空间中使用相同的pod启动相同的测试。如果出现故障,我们需要检查以下几点:
- 检查部署所公开的端口
- 检查容器/ pod所公开的端口
- 检查在您的命名空间中创建的任何网络策略
- 检查任何安全策略或可能使其被阻止的其他因素。
确保应用程序运行正常后,我们继续检查服务和ingress连接。
在下一部分,我们将继续学习如何像专家一样进行调试。敬请期待,不要错过!点击链接转到下一页,再见!
作者:JJotah
更多技术干货请关注公众号 "云原生数据库"
【squids.cn】 全网zui低价RDS,免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等