k8spodpod不通（k8s pod service deployment）

云原生|K8s中external-traffic-policy导致的业务问题

1、external-traffic-policy导致的业务问题解析 在kubernetes（K8s）中，external-traffic-policy 是 Service 资源的一个重要属性，它决定了外部流量如何被分发到集群内的 Pod。这个策略有两个可选值：Local 和 Cluster，它们各自有不同的行为模式和业务影响。

2、云原生安全资讯 | 云漏洞案例：Unit42 发现 GKE 组合漏洞可导致 k8s 提权 Unit42 团队（隶属于 Palo Alto networks）近期发布了一项重要研究成果，揭示了 google Kubernetes Engine （GKE） 中存在的两个漏洞，当这两个漏洞被组合利用时，攻击者可以获得 KuberneTES （k8s） 集群的完整控制权限。

3、SSH客户端尝试登录K8s集群中的SSH POD时，消息流程如下：外部SSH客户端发起请求，数据包通过SNAT后由K8s匹配路由表并发送出去。然而，主路由表仅包含默认路由发给VRF1，但SSH业务通过VRF2处理，导致SSH客户端出现连接超时等错误，登录失败。

4、验证nginx业务：查看service之后可以使用curl cluster-ip来确认Nginx的业务是否好用，如果看到Thank you for using nginx代表nginx业务是正常的。总体来说，Play with Kubernetes是一个很好的免费体验平台，对于日常学习、理解和实践K8s基础概念是完全够用了。

5、推荐一款K8s pod诊断工具：kubectl-deBUG，它是一个简单、易用、强大的kubectl插件，能够帮助你便捷地进行Kubernetes上的Pod排障诊断。无需预装任何额外的排障工具，业务容器可以保持最小化。

6、K8s编排能力：实现跨主机的动态管理，提供自动化、可扩展性与云原生特性。Helm封装：通过模版制作与打包机制，增强部署的灵活性与可定制性。Operator技术的核心作用：业务能力云原生化：提供声明式、自动化、可迭代的中间件部署与管理方案。CRD与Controller结合：实现高级自动化运维与业务能力扩展。

k8s中Pod状态及问题排查方法

1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackoff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

2、解决方法：仔细检查Pod的YAML配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。

3、Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

网站迁移至k8s后变慢了

1、网站迁移至Kubernetes后变慢可能由以下因素导致：配置不当：Pod资源限制：Pod的cpu和内存限制设置过低，导致应用在处理高负载时资源不足。Service和ingress配置：配置不当可能导致流量路由错误或网络延迟增加。Kubernetes集群资源限制：节点数量不足：集群中的节点数量无法满足大量Pod同时运行的需求。

2、要将Jenkins构建环境迁移到K8S集群，关键在于利用K8S的弹性资源管理和Jenkins的Kubernetes插件。以下是迁移的加速流程：准备K8S集群和Jenkins Master 确保有一个稳定运行的K8S集群。准备一台Jenkins Master，确保其正常运行。安装Kubernetes插件 在Jenkins Master上，进入“系统管理” - “插件管理”。

3、公司服务迁移到k8s后，发现前端页面打开频繁时未能有效利用缓存，这导致页面响应速度受限。

4、可移植性：k8s提供了有状态服务的支持（Statefulset），通过PersistentVolume（PV）和PersistentVolumeClaim（pvc）等资源声明数据的存储，用来屏蔽底层存储的差异性。这使得服务的迁移变得容易，因为使用者无需关心底层存储的具体实现，只需声明PV和PVC来使用存储即可。

搭建一个k8s单机版,yaml已经创建好,但pod状态一直处于pEnd

1、资源不足：原因：如果集群中的资源不足，Pod可能无法被调度到任何节点上，从而处于Pending状态。解决方法：检查集群的资源使用情况，确保有足够的资源可供Pod使用。可以考虑增加节点或调整Pod的资源请求和限制。调度问题：原因：调度器可能由于某些原因无法找到合适的节点来部署Pod。

2、假设一位机器学习研究人员想要在PyTorch环境中使用基于python的GPU进行测试，她请求她的工程团队提供一个带有两个GPU的Jupyter笔记本，以及她所有的库。然而，工程团队告诉她这需要三天时间，包括获取GPU、创建堆栈以及授予对JupyterHub的访问权限。

3、针对k8s 10版本中coredns一直处于pending状态的问题，本文提供了一系列解决方案。首先，需要注意的是，当使用kubeadm init后，关闭cni可以解决部分问题。在进行kubeadm init操作前，应该在其他节点上也执行此操作，确保整个系统的一致性。对于kube-flannel.yml文件的修改，是一种推荐的解决方案。

4、当创建Pod时，该Pod保持Pending状态。

5、在Kubernetes（K8s）中，当pod状态显示为“ContainerCreating”，这意味着pod已经由调度器分配至特定节点，该节点的kubelet正在创建容器。在此阶段，系统会进行容器创建操作。一旦所有容器启动并运行，pod状态将从“ContainerCreating”转变为“Running”。

Kubernetes组件之CoreDNS及DNS解析不通问题

如果CoreDNS也无法解析该请求，则可能会根据配置将请求转发给外部的DNS服务器。DNS解析不通问题分析及解决方案 问题描述：在某些情况下，Pod可能无法解析特定的域名，即使这些域名在CoreDNS中已正确配置。这个问题通常与nodeLocalDNS的配置有关，特别是与其转发DNS请求的方式有关。

解决方案是修改为直接使用全局DNS服务器的IP进行转发，即forward . 200.0.3。通过此方法解决了域名解析不通的问题。为了测试和调试DNS相关问题，提供了一个容器内的测试工具，该工具内置了nslookup工具、curl等常用工具，方便进行DNS排错。以下是用于测试的yaml脚本示例。

另一种情况下，服务器重启后仍遇到coredns异常，可能是由于/etc/resolv.conf文件丢失所致。检查pod的日志和dns配置文件，可以发现类似问题。此问题的解决方式与场景一相同，即重新配置/ETC/resolv.conf文件。如果coredns部署后状态在CrashLoopBackOff和Error之间不断切换，查看日志会发现coredns无法启动的迹象。

为了彻底解决此问题，必须重新配置集群环境。先执行kubeadm reset命令，然后在master节点上运行新的kubeadm init命令，并正确指定CIDR网段。此操作需根据网络实际情况进行调整，以确保master节点和工作节点与Calico网络插件间的网络隔离。面对复杂的技术问题，耐心和持续的学习是关键。

CoreDNS：CoreDNS 是专为 Kubernetes 设计的 DNS 服务器，从 Kubernetes 14 版本开始成为默认选择。它是一款灵活且可扩展的 DNS 服务器，能够实现在集群内部署的服务发现和域名解析。CoreDNS 通过监听 Kubernetes API，动态地更新和维护 DNS 记录，确保集群内的 pod 和服务能够通过 DNS 名称进行通信。

默认情况下，Kubernetes集群内的容器要解析外部域名时，CoreDNS会将请求转发给/etc/resolv.conf文件里指定的上游DNS服务器。有时，我们可能需要在集群内全局劫持某个域名时，可以利用HOSTS插件来帮忙。hosts插件会每隔5s将需解析的信息重新加载到coredns当中，当你有任何变化时直接更新它的配置区块即可。