pod创建后查不到？ pod创建过程？
【技术干货】k8s学习-Calico的默认配置
1、Calico后端（calico_backend）默认配置：bird说明：Calico使用bird构建BGP mesh的全连接网络。Bird是Linux提供的一个BGP客户端工具，负责读取路由信息，并与其他节点的bird一起构建BGP网络。
2、Calico 适用场景：在 k8s 环境中，pod 之间需要隔离。设计思想：Calico 不采用隧道或 NAT 来实现转发，而是将所有二三层流量转换为三层流量，并通过主机上的路由配置完成跨主机转发。设计优势：更优的资源利用：三层路由方法完全抑制二层广播，减少资源开销。
3、配置CONTAINERd：确保containerd已正确配置为kubernetes的容器运行时。初始化集群：在控制端执行kubeadm init命令初始化集群，生成和修改配置文件，完成kubeadm的初始化和kubectl的授权。扩容集群：在node节点上执行kubeadm join命令，将节点加入集群，确保集群状态为Ready。
4、// calico有两种模式：ipip（默认）、bgp，bgp效率更高。如果宿主机在同一个网段，可以使用ipip模式；如果宿主机不在同一个网段，POD通过BGP的hostGW是不可能互相通讯的，此时需要使用ipip模式（如果仍想使用bgp模式，除非你在中间路由器上手动添加路由）。
5、调整calicao 网络插件的网卡发现机制，修改IP_AUtodETECTION_METHOD对应的value值。官方提供的yaml文件中，ip识别策略（IPDETECTMETHOD）没有配置，即默认为first-found，这会导致一个网络异常的ip作为NodeIP被注册，从而影响node-to-nodemesh。
K8s出现问题,排查秘诀!
网络问题：检查Calico等网络插件的状态，确保网络通信正常。存储问题：Pod挂载的共享存储连接不上可能导致PoD启动异常。此时，需要检查共享存储和存储卷的状态是否正常。代码问题：应用程序代码在容器启动后失败。需要排查应用程序代码，确保其能在容器环境中正确运行。
k8s中Pod状态及问题排查方法
含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
内存和CPU超标：Pod中的应用出现内存泄露等问题，导致内存迅速增加，可能被系统kill，影响节点正常提供服务。解决办法是进行压测，确定应用所需的内存和CPU资源，并在Pod配置中进行资源限制。网络问题：检查Calico等网络插件的状态，确保网络通信正常。存储问题：Pod挂载的共享存储连接不上可能导致Pod启动异常。
解决方法：仔细检查Pod的YAML配置文件，确保语法正确且配置合理。可以使用kubectl describe pod 命令查看Pod的详细信息，以获取更多关于错误的信息。总结：Pod状态一直处于Pending通常是由于资源不足、调度问题、镜像拉取问题、权限问题或配置错误等原因导致的。
检查节点状态：使用kubectl get nodes命令查看集群中所有节点的状态。如果节点有问题（如处于“NotReady”状态），DaemonSet可能无法在该节点上调度Pod。此时，需要解决节点的问题，使其恢复为“Ready”状态。
要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
Kubernetes部署nginx,在浏览器中无法访问怎么办?
1、使用Dashboard方式部署Nginx后访问问题 配置部署方便，但部署后需要检查Pod、Service等状态是否正常。访问问题可能出现在网络配置或端口映射上。命令行方式部署nginx访问问题解决步骤 创建nameSpace：用于隔离资源，避免命名冲突。
2、首先，确认你的服务是否正确暴露和可用。在 Kubernetes 中，确保服务的端口正确暴露，并且目标 Nginx 部署的端口与你的期望一致。你可以通过查看服务定义和日志，检查服务是否已成功启动并正常运行。其次，检查网络策略设置。确保你的 Kubernetes 集群中的网络策略允许从你的请求源访问到 Nginx。
3、使用frontendsvc.yaml文件定义服务，并通过Ingress实现URL路由至前端服务。 部署应用到Kubernetes集群 创建命名空间，例如k8sdemo。 使用kubectl命令将后端和前端应用部署到k8sdemo命名空间下。 配置dns解析 在hosts文件中配置DNS解析，将域名映射到Kubernetes集群内任意节点IP。
记录一次calico无法启动问题的排查过程
1、尝试重启containerd或Docker服务，看是否能解决问题。使用systemctl restart containerd或systemctl restart docker重启服务。检查内核参数：确认系统的内核参数是否支持容器的正常运行。检查如CONFIG_NAMEspaceS、CONFIG_IPC_NS等内核配置是否启用。
2、检查网络配置和防火墙规则：确认集群的网络配置是否正确，包括CIDR、节点间的通信方式等。检查是否有防火墙规则阻止了calico-node与其他组件的必要通信。调整系统资源限制：如果系统的资源限制（如线程数）导致kubelet无法初始化线程，从而影响calico-node的启动，可以尝试增加系统的资源限制。
3、网络问题：检查Calico等网络插件的状态，确保网络通信正常。存储问题：Pod挂载的共享存储连接不上可能导致Pod启动异常。此时，需要检查共享存储和存储卷的状态是否正常。代码问题：应用程序代码在容器启动后失败。需要排查应用程序代码，确保其能在容器环境中正确运行。
4、kubelet sandbox启动失败可能由多种原因引起，以下是一些排查和解决此问题的步骤：检查kubelet服务状态：确保kubelet服务正在运行。使用命令systemctl status kubelet来检查kubelet服务的状态。如果服务未运行，则使用systemctl start kubelet命令启动kubelet服务。
5、在排查过程中，发现某些服务名称解析失败的情况仅出现在某台新加入集群的节点上，且问题出现于该节点重启后。考虑到节点资源问题及重启可能对服务状态的影响，检查kube-proxy进程状态，发现相关进程均运行正常，排除了资源分配和kube-proxy本身的问题。
K8s中Pod生命周期和重启策略
1、例如，Deployment通常会将Pod的重启策略设置为Always，以确保Pod在出现问题时能够自动恢复。K8s重启的时间间隔和最大延迟 Kubernetes在重启Pod时，会遵循一定的时间间隔和最大延迟规则。具体来说，重启的时间间隔通常是2的幂次方倍增（即2n），最大延迟时间通常为5分钟。
2、重启策略有三种：Always、OnFailure和Never。如果设置为Always，那么无论因为什么原因停止，Pod都会自动重启。如果设置为OnFailure，则只有Pod非正常停止时（例如，因为崩溃或被杀死）才会重启。如果设置为Never，则Pod在任何情况下都不会自动重启。
3、在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。
