k8s进pod（k8s进pod命令）
内网k8s机群pod如何上网
内网K8s机群中的POD上网可以通过配置kubernetes的Service和Endpoints、使用Hostnetwork、nodePort或ExternalIPs等方式实现。
若办公网络至交换机间有多个网关，需在这些网关上设置合适的路由。至此，基本打通了外部直接访问Pod IP的能力。然而，Cluster IP访问存在限制，通常Calico并未广播Service IP。可通过检查交换机接收到的IP段确认。解决方案是打开相关设置。为了在无需记忆IP的情况下访问服务，将K8s内部dns暴露出来。
flannel VXLAN模式在K8s中的实现原理主要包括以下几点：CNI接口规范：Flannel通过CNI接口规范为每个PoD分配独立的IP地址，从而解决了跨节点网络的路由问题。Pod网络连接：在K8s集群中，Pod通过veth设备与主机网络命名空间连接，形成虚拟网络接口对。这些veth设备进一步通过网桥cni0进行路由转发，实现Pod间的通信。
K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据
原因： conntrack表项问题：在K8S环境中，通过NodePort暴露的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当Pod重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。
首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入input链，指向DNAT问题。
当 Pod 状态为 CrashLoopBackOff 时，表示容器在启动后立即崩溃或退出。这可能是容器配置错误、应用程序错误、内存不足或权限问题导致。排查此类问题时，需详细检查容器配置、应用程序日志、内存使用情况及权限设置。Pod 状态为 Failed 通常意味着容器已终止，并且至少一个容器以失败方式退出。
查看kubectl describe命令的输出将使您更加清楚。如果Pod保持挂起状态，则可能是一个问题，根本原因可能是节点中的资源不足。或者，如果您为不可用的容器指定主机端口，或者该端口已在Kubernetes集群的所有节点中使用，则Pod可能未就绪。结论 kubernetes中的故障排除似乎是一项艰巨的任务。
当pod出现crash状态，容器频繁重启，使用kubelet logs 方法可能无法获取到所需日志时，可以采用kubectl previous参数进行解决。该参数的使用原理基于kubelet在pod失败后会保留前几个容器的失败记录。这为后续查看提供了前提条件。
如何在集群外部通过ip直连Pod?
如果要在集群外部访问pod，通常可以使用三种方式：NodePort，HostPort和LoadBalancer。其中NodePort最为常用，在每个kube-proxy节点上开启代理端口以供外部访问。除此之外有没有别的办法可以在集群直接访问到Pod呢？答案是有的。
首先，确保办公网段与Kubernetes集群网段不同，实现网络连接的关键在于路由方案。建议选择三层路由方案或Host-GW，避免因数据包封包解包过程中路由方向丢失。我所用的集群是Calico，且关闭了IPIP模式。具体IP配置需依据Calico文档。选择Calico的Route Reflectors（RR）或Full-Mesh模式时，需权衡资源消耗。
首先，准备一个在五个pod中运行的应用程序。创建一个服务对象，使用服务负载平衡器配置文件示例。配置文件描述了一个名为hello-world的部署，包含5个副本的pod，使用指定的容器镜像和端口。创建Deployment对象和关联的ReplicaSet对象，ReplicaSet拥有五个pod，每个pod运行Hello World应用程序。
通过将外部服务抽象为Kubernetes Service，并手动指定Endpoints（如果外部服务的IP地址是固定的），Pod可以像访问集群内部服务一样访问外部服务。这种方法需要一定的配置工作，但能够提供较为灵活和可靠的网络访问。使用HostNetwork 让Pod共享节点的网络，这样Pod可以直接访问节点的IP地址，从而访问外部网络。
OpenShift中存在三层IP地址概念，要从集群外部访问Pod中的应用，通常有两种方式。使用Ansible默认配置部署OpenShift集群时，在集群Infra节点上运行的HAProxy Pod会监听170.0.1上的10443和10444端口。Router服务的部署需要在集群Infra节点上实现，端口只能被占用一次。
通过vagrant+virtualbox安装k8s找不到pod问题
通过vagrant+virtualbox安装k8s集群的小伙伴都会碰到找不到pod的问题，但是通过api服务查看，这些pod却是活的好好的。 原因是 ，在virtualbox组网的过程中，采用了双网卡方案，网卡1使用NAT地址转换用来访问互联网，网卡2使用Host-only来实现虚拟机互相访问。
安装vagrant相对简单，首先下载virtualbox，然后通过vagrant命令行开始创建虚拟机。需要注意的是，vagrant默认与virtualbox集成，若想用VMware，需额外安装vmware utility。windows 11用户可能遇到与virtualbox的兼容问题，建议考虑vmware作为替代。要创建虚拟机，需从vagrant官网获取box文件，如CentOS7的box。
新建/etc/systemd/system/Docker.service.d/http-proxy.conf，添加配置内容。安装virtualbox 安装k8s集群使用vagrant 参考jimmysong的vagrant教程 kubernetes-vagrant-centos-cluster，节点数量应根据个人机器配置调整（参考kubernetes-vagrant-centos-cluster）。
k8s中Pod状态及问题排查方法
1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
2、解决方法：仔细检查Pod的YAML配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。
3、如果原因是Pod无法安装请求的卷，请确保清单适当地指定其详细信息并确保Pod可以访问存储卷。或者，如果该节点没有足够的资源，则手动从该节点删除Pod，以便将Pod调度到另一个节点上。否则，可以扩展节点资源容量。如果使用nodeSelector安排Pod在Kubernetes集群中的特定节点上运行，就会发生这种情况。
4、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
K8S故障检查-Pod处于CONTAINERCreating状态
常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。
面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。
问题描述：Pod处于终止状态或状态未知，通常与节点故障或删除操作相关。解决办法：强制删除Pod；检查节点的健康状态，必要时重启节点组件；检查集群的删除操作是否正确执行。UnexpectEDAdmISSionError：问题描述：Pod因节点磁盘空间不足而无法正常创建或运行。
