首页
关于
留言
接口
搜索
资讯
技术
资源
悦读
杂记
首页
登录
登录
搜索
emer
累计撰写
58
篇文章
累计收到
0
条评论
首页
栏目
资讯
技术
资源
悦读
杂记
首页
登录
页面
首页
关于
留言
接口
包含标签 【K8s】 的文章
2024-5-21
K8s运维:Pod常见错误及处理思路
Pod常见错误及处理思路Pod可能会出现启动和运行时错误。启动错误包括:ImagePullBackoffImageInspectErrorErrImagePullErrImageNeverPullRegistryUnavailableInvalidImageName运行时错误包括:CrashLoopBackOffRunContainerErrorKillContainerErrorVerifyNonRootErrorRunInitContainerErrorCreatePodSandboxErrorConfigPodSandboxErrorKillPodSandboxErrorSetupNetworkErrorTeardownNetworkError1.ImagePullBackoffImagePullBackoff 是一个 Kubernetes 中常见的错误状态,它表示 Kubernetes 试图从容器镜像仓库拉取容器镜像,但出现了一些问题,导致暂时无法完成这个操作。这个状态通常是临时的,Kubernetes 将会按退避算法(即逐渐增加间隔时间)重试拉取操作。常见原因镜像不存在:指定的镜像名或标签在镜像仓库中不存在。拼写错误:在 image 字段中镜像名称或标签拼写错误。私有镜像仓库凭证问题:对于存储在私有仓库中的镜像,可能是因为 Kubernetes 没有正确配置访问私有镜像仓库的凭证。网络问题:Kubernetes 节点无法访问或连接到镜像仓库,可能是由于网络配置或者代理设置的问题。仓库限流或访问限制:一些公共镜像仓库(如 Docker Hub)对拉取频率有限制,可能触发了这些限制。错误处理检查镜像名称和标签:确认 image 字段中的名称和标签是否正确,且镜像确实存在于镜像仓库中。检查仓库凭证: 确认是否已为 Kubernetes 集群提供了私有仓库的访问凭证。 检查 Kubernetes 的 Secret 是否正确创建,并且被 Pod 引用。网络连接检查: 检查 Kubernetes 集群的网络配置,确认节点可以访问外部网络。 如果使用了代理,请确保代理配置正确。检查镜像仓库限制: 如果使用的是公共镜像仓库,如 Docker Hub,检查是否有拉取次数限制或是否需要认证。查看日志和事件: 使用 kubectl describe pod <pod-name> 查看 Pod 的事件,了解更多错误信息。 使用 kubectl logs <pod-name> 查看 Pod 日志,获取额外的错误细节。2.ImageInspectErrorImageInspectError 是 Kubernetes 在尝试检查镜像时遇到的一个错误状态,这通常发生在 Kubernetes 在拉取镜像后,尝试读取镜像的元数据时遭遇问题。这种错误可能由多种原因导致,以下是一些常见的原因及其解决方法:常见原因损坏的镜像:镜像文件可能在传输过程中被损坏,或者镜像本身存在问题。错误的镜像格式:有时候镜像可能并不符合 Docker 或 Kubernetes 所支持的格式。存储问题:节点上的存储系统出现问题,如磁盘满、文件系统损坏等,可能会导致无法正确读取镜像文件。镜像拉取后的权限问题:可能是因为节点上的 Docker 或容器运行时的配置问题,导致拉取下来的镜像无法被正确读取。运行时组件问题:容器运行时(如 Docker、containerd)存在问题,可能是软件缺陷或配置错误。处理方式重新拉取镜像: 删除有问题的 Pod,让 Kubernetes 尝试重新创建并拉取镜像。 在有问题的节点上手动尝试拉取镜像,以查看是否存在相同问题。检查镜像完整性和兼容性: 确保镜像没有损坏,可以在其他环境中测试该镜像。 确认镜像格式正确,并且兼容 Kubernetes 所使用的容器运行时。检查节点存储: 检查节点的磁盘空间,确保有足够的空间用于存储镜像。 检查文件系统是否完好,没有损坏或错误。检查权限和配置: 确认容器运行时和节点上的安全策略是否允许正常访问和处理这些镜像。 检查是否存在与 SELinux、AppArmor 相关的安全限制问题。检查和重启容器运行时: 检查 Docker 或其他容器运行时的状态,必要时进行重启。 检查容器运行时的日志,寻找可能的错误信息或警告。查看 Kubernetes 事件和日志: 使用 kubectl describe pod <pod-name> 命令查看 Pod 的状态和相关事件。 查看相关节点和容器运行时的日志以获得更多诊断信息。3.ErrImagePullErrImagePull 是 Kubernetes 中遇到的一种常见错误,它发生在 Kubernetes 尝试从容器镜像仓库拉取容器镜像时失败。这个错误可能由多种原因引起,包括但不限于网络问题、认证错误、镜像名称或标签错误等。以下是一些常见原因及其解决方法:常见原因镜像不存在:在仓库中找不到指定的镜像或标签。拼写或路径错误:镜像名称或标签拼写错误,或者路径指定不正确。认证失败:对于私有仓库,可能是因为没有提供正确的认证凭据。网络问题:拉取镜像的节点无法访问镜像仓库,可能是因为网络配置或者代理设置的问题。镜像仓库问题:镜像仓库服务器可能宕机或无法处理请求。处理方式检查镜像名称和标签: 确保在 Pod 定义中指定的镜像名称和标签完全正确。 在不同的环境中测试镜像名称,比如在本地 Docker 环境中。确认认证信息: 如果镜像存储在私有仓库中,确保已在 Kubernetes 集群中创建了正确的 Secret,并在 Pod 定义中使用 imagePullSecrets 引用该 Secret。 检查 Secret 中的认证信息是否正确,例如 Docker 登录凭据。检查网络连接: 确认 Kubernetes 集群内的节点可以访问外部的镜像仓库。可以在节点上手动尝试拉取镜像。 如果集群使用代理,检查相关的代理设置是否正确。检查镜像仓库状态: 确认镜像仓库是否运行正常,特别是当使用私有或自托管的仓库时。检查 Kubernetes 集群和节点状态: 使用 kubectl describe pod <pod-name> 来获取 Pod 的状态和事件信息,这通常能提供关于为什么镜像拉取失败的线索。 检查集群中相关节点的状态,确保它们运行正常且资源不是过度紧张。查看日志: 查看相关的 Kubernetes 组件(如 kubelet)的日志以获取详细的错误信息。4.ErrImageNeverPullErrImageNeverPull 是 Kubernetes 在处理容器镜像时遇到的一个特定错误。这个错误表明 Kubernetes 被配置为不去拉取镜像,通常发生在以下几种情况:常见原因Pod 配置了 ImagePullPolicy 为 Never:在这种情况下,Kubernetes 期望容器镜像已经存在于节点上,而不会去尝试从镜像仓库中拉取它。使用本地开发环境:在本地开发环境(如 Minikube 或 Docker Desktop 的 Kubernetes 集群)中,可能会预先加载或构建镜像到本地环境中,而不需要从远程仓库拉取。离线环境或策略限制:在某些离线环境中,可能不允许或无法从外部镜像仓库中拉取镜像。处理方式检查 ImagePullPolicy: 确认 Pod 定义中的 imagePullPolicy 设置。如果设为 Never,Kubernetes 将不会尝试拉取镜像。 如果需要 Kubernetes 从远程仓库拉取镜像,应将 imagePullPolicy 设置为 Always 或 IfNotPresent。确保镜像在节点上存在: 如果 imagePullPolicy 设为 Never,确保需要的镜像已经在所有可能运行该 Pod 的节点上预先加载。 在节点上使用类似 docker images 的命令来检查镜像是否存在。调整开发或部署策略: 在本地开发环境中,如果使用如 Minikube 或 Docker Desktop,可以通过构建镜像直接到本地 Kubernetes 环境中,或者将镜像手动加载到这些环境里。 在离线或受限环境中,需要将所需的所有镜像事先加载到所有节点上。5.RegistryUnavailableRegistryUnavailable 是 Kubernetes 或其他容器编排工具中的一个错误,表示无法访问或连接到指定的容器镜像仓库。这个错误通常表明 Kubernetes 集群的节点无法访问用于拉取容器镜像的注册中心(registry)。常见原因镜像仓库服务器宕机:容器镜像仓库可能由于各种原因(如维护、配置错误、网络问题)而暂时不可用。网络问题:Kubernetes 集群的节点可能因为网络配置错误或连通性问题无法访问镜像仓库。DNS 解析问题:如果 Kubernetes 集群的节点无法正确解析镜像仓库的 DNS 名称,可能会导致无法访问仓库。认证失败:对于需要认证的私有仓库,如果没有提供正确的凭据或凭据过期,也可能导致无法访问。处理方式检查镜像仓库的状态: 确认仓库服务器是否运行并且可以正常访问。这可能涉及检查仓库的状态页面、服务健康检查或尝试手动从仓库拉取镜像。检查网络连接: 确保 Kubernetes 集群的节点可以访问镜像仓库的网络。可以在节点上手动尝试 ping 或 traceroute 到镜像仓库的地址。 如果使用了网络策略或防火墙,确保它们没有阻止对镜像仓库的访问。验证 DNS 配置: 检查 Kubernetes 集群的 DNS 解析是否正常工作。你可以在 Pod 中尝试解析仓库的 DNS 名称来测试这一点。检查认证信息: 如果你的镜像仓库需要登录,确保 Kubernetes 集群中正确设置了镜像拉取的 Secret,并且它们没有过期。 检查 imagePullSecrets 是否已被正确应用到 Pod 配置中。检查仓库的配置和证书: 对于使用 HTTPS 的仓库,确保相关的 SSL/TLS 证书是有效的,并且 Kubernetes 集群的节点信任这些证书。 如果你的环境有特殊的证书要求(如自签名证书),确保这些证书已被正确导入和配置。6.InvalidImageNameInvalidImageName 错误在 Kubernetes 中通常指的是 Pod 无法启动,因为其定义中的容器镜像名称不符合预期格式或包含了不正确的字符。这种问题通常发生在 Kubernetes 的 Pod 配置中,特别是在 image 字段。常见原因格式错误:镜像名称、标签(tag)或者域名(registry domain)的格式可能不正确。例如,镜像名称可能缺少了必要的部分(如域名或标签),或者包含了非法字符。使用了不存在的标签或镜像:在指定的仓库中,镜像标签可能不存在,或者整个镜像可能不存在。拼写错误:简单的拼写错误,如将 latest 错误地写作 latset,也会导致这个问题。不完整或缺少仓库地址:如果没有指定完整的仓库地址或者使用了错误的仓库地址(例如私有 Docker Registry 的地址),可能会导致此错误。处理方式检查镜像名称的格式: 确保镜像名称完整,包括仓库地址、镜像名和标签(如 registry.example.com/myimage:tag)。 镜像名称和标签应只包含合法字符。验证镜像和标签的存在: 确认你试图使用的镜像和标签在 Docker Registry 中确实存在。 通过运行 docker pull <image_name> 或相应的命令来本地测试。检查拼写和空格: 确认镜像名称、仓库地址和标签的拼写正确,没有不必要的空格或拼写错误。使用默认仓库(如适用): 如果你使用的是 Docker Hub 的公共镜像而没有指定仓库地址,可以省略仓库地址。例如,使用 ubuntu:latest 而不是 docker.io/ubuntu:latest。更新和重试: 一旦镜像名称被更正,更新你的 Kubernetes 配置(如 Deployment、Pod 等),然后重新部署。7.CrashLoopBackOffCrashLoopBackOff 是 Kubernetes 中的一个常见错误,指的是当一个或多个容器在 Pod 中重复启动、崩溃、重启的循环。这通常是由于应用程序在启动后遇到错误而崩溃导致的。理解和解决这一问题,需要查看 Pod 的日志,检查应用程序的运行环境和配置。常见原因配置问题:配置错误(如环境变量设置错误)、缺少配置文件或配置不正确。资源不足:内存或 CPU 资源分配不足,导致应用启动不了或在运行时崩溃。应用程序错误:应用代码中存在的错误或异常,导致应用崩溃。权限问题:应用试图访问没有权限的资源(如文件系统、网络接口)。依赖问题:应用依赖的服务(如数据库、其他微服务)无法访问或未准备好。健康检查失败:Kubernetes 的 liveness 或 readiness 探针失败,导致容器重启。处理方式查看 Pod 日志:kubectl logs <pod-name> 1这通常是理解为什么 Pod 崩溃的第一步。检查资源分配: 使用 kubectl describe pod <pod-name> 查看是否有资源相关的错误(如 OOMKilled)。 根据需要调整 Pod 的资源请求和限制。检查应用健康检查(Probes): 确认 liveness 和 readiness 探针是否配置正确。 如果探针配置错误,Pod 可能会被频繁重启。检查依赖服务: 确保所有依赖的外部服务可用,并且网络配置正确。分析应用程序日志和输出: 确认应用程序是否因错误而退出,或是否有异常输出。 考虑在应用程序中增加更多日志输出以帮助诊断问题。调试 Pod: 如果日志不足以诊断问题,可以尝试使用 kubectl exec -it <pod-name> -- /bin/bash 进入容器内部进行调试。 检查文件系统、运行进程和网络连接等。回滚变更: 如果问题发生在部署新版本或更改配置后,考虑回滚这些变更。8.RunContainerErrorRunContainerError 在 Kubernetes 环境中出现时,通常意味着 Kubelet 在尝试运行容器时遇到了问题。这种错误可能是由各种原因造成的,包括容器镜像、网络配置、存储问题或其他环境设置的问题。常见原因镜像问题:无法拉取镜像(比如镜像不存在或私有仓库认证失败),或者镜像损坏。配置错误:Pod定义中的错误,比如命令行参数错误、环境变量问题等。资源限制:请求的资源超过了节点的可用资源。存储/卷挂载问题:无法挂载配置的卷,例如由于权限问题、不存在的路径、网络存储问题等。网络问题:容器网络配置错误,或者网络策略限制了所需的连接。系统级问题:节点问题(如 Docker daemon 故障、节点上其他服务占用了必要资源等)。处理方式检查事件日志:使用 kubectl describe pod <pod-name> 查看与 Pod 相关的事件日志,这通常提供了失败的具体原因。验证容器镜像: 确认指定的镜像是否存在,并且可以从运行节点上拉取。 检查是否有私有镜像仓库认证问题。检查 Pod 配置: 确保 Pod 定义中的所有参数都是正确的。 检查容器的启动命令和参数。检查资源请求和限制: 确认 Pod 的资源请求(CPU、内存)是否过高,导致无法在节点上调度。检查存储和卷: 检查 Pod 定义的卷是否都可以正确挂载。 检查是否存在权限问题或路径错误。网络配置: 确认网络策略和容器的网络配置是否正确。 检查是否有防火墙或安全组限制通信。节点健康状况: 检查节点的健康状况,包括 Docker 或容器运行时的状态。 确认是否有足够的资源来运行容器。查看 kubelet 日志: 如果以上步骤都无法解决问题,可以在相应的节点上查看 kubelet 的日志,获取更深入的信息。重启 Pod: 在某些情况下,简单地重启 Pod 可能解决问题(例如,在解决了底层资源限制问题后)。9.KillContainerErrorKillContainerError 在 Kubernetes 环境中通常指 Kubelet 在尝试停止一个容器时遇到了错误。这个问题可能是由于底层容器运行时的问题、资源问题、或与特定容器有关的特定状态或配置问题导致的。常见原因容器运行时问题:例如 Docker 或其他容器运行时出现问题或不响应。节点问题:节点上的资源不足(如内存、CPU),或者节点的磁盘空间不足。系统级问题:例如,操作系统层面的问题,比如内核错误或者资源紧张。网络问题:网络延迟或中断可能导致管理命令无法及时传达到容器。Kubernetes 错误:Kubernetes 自身的错误或 Bug 有时也会导致这种情况。处理方式查看容器和节点日志: 用 kubectl describe pod <pod-name> 查看 Pod 的状态和相关事件。 检查节点(如 Docker 节点)上的日志,以确定是否有与停止容器相关的错误信息。检查容器运行时: 检查容器运行时的状态和日志(例如 Docker 的状态和日志)。 尝试手动停止容器,看是否有详细的错误信息。资源使用情况: 检查节点的资源使用情况(CPU、内存、磁盘空间)。 如果资源使用率过高,考虑扩容或优化应用以减少资源消耗。系统和网络健康状况: 确认节点的系统健康状况和网络连接状态。重启相关组件: 在某些情况下,重启 kubelet 或 Docker 服务可以恢复正常状态。 但这应该是最后的手段,因为它可能影响到节点上的其他容器。10.VerifyNonRootErrorVerifyNonRootError 是 Kubernetes 中的一个错误,指示 Pod 的容器因为某些原因无法以非 root 用户身份启动。这通常与 Pod 的安全上下文设置有关,特别是当在 Pod 或容器规范中明确要求以非 root 用户运行时。常见原因安全上下文配置:在 Pod 定义中的 securityContext 配置要求容器以非 root 用户运行,但实际上容器尝试以 root 用户启动。容器镜像配置:容器镜像可能默认以 root 用户运行,与 Kubernetes 的安全要求冲突。权限或文件系统问题:容器中的应用可能需要以 root 用户权限来访问某些文件或执行特定操作,但 Kubernetes 的安全策略阻止了这一行为。处理方式检查和修改 Pod 安全上下文: 查看 Pod 或容器的 securityContext 设置,确保 runAsNonRoot: true 和 runAsUser: <non-root-user-id> 配置正确。 如果设置了 runAsNonRoot 但没有指定 runAsUser,确保容器镜像以非 root 用户作为默认用户。检查和修改容器镜像: 确认容器镜像的默认用户。你可以通过检查 Dockerfile 中的 USER 指令来了解这一点。 如果需要,更改镜像以使用非 root 用户运行,或者创建一个新的镜像版本,确保以非 root 用户启动。调整应用程序的权限需求: 如果应用确实需要特定的权限,请仔细评估这些权限是否必要,以及是否可以通过修改应用逻辑或配置来避免这些需求。 有时候,你可能需要调整文件系统的权限,使非 root 用户也能访问必要的文件或目录。测试和验证: 在进行更改后,确保在一个安全的测试环境中验证这些更改,以确保应用程序仍然按预期工作。11.RunInitContainerErrorRunInitContainerError 在 Kubernetes 环境中出现时,表示初始化容器(Init Container)启动失败。初始化容器是在 Pod 的应用容器启动之前运行的,通常用于设置环境、初始化配置或等待外部依赖。常见原因配置错误:Init 容器的配置或命令行指令有误,导致容器无法正确启动或执行所需任务。镜像问题:Init 容器使用的镜像无法拉取,或镜像本身有问题(例如损坏或不包含所需的执行文件)。资源限制:资源限制太严格,导致容器无法获取足够的 CPU 或内存来启动。权限问题:权限设置不当,使得容器无法访问所需的文件系统或网络资源。外部依赖问题:容器可能在等待外部资源或服务(如数据库、配置服务等),而这些依赖项未能按预期提供服务。处理方式检查 Init 容器的定义和日志: 使用 kubectl describe pod <pod-name> 查看 Pod 详细信息和事件日志。 使用 kubectl logs <pod-name> -c <init-container-name> 查看 Init 容器的日志。检查和修改容器配置: 确保 Init 容器的配置(如执行命令、环境变量等)正确无误。 检查 Init 容器使用的镜像是否正确且可访问。调整资源限制: 如果怀疑资源限制问题,可尝试增加 Init 容器的 CPU 或内存限制。检查权限和安全策略: 确保 Init 容器拥有执行其任务所需的权限,包括对文件系统、网络和其他 Kubernetes 资源的访问。处理外部依赖: 如果 Init 容器依赖于外部服务或资源,确保这些服务可用且网络通畅。查看 Kubernetes 系统日志: 如果上述方法都无法解决问题,可以检查 Kubernetes 节点上的系统日志,查找可能的系统级错误信息。12.CreatePodSandboxErrorCreatePodSandboxError 是 Kubernetes 中出现的错误,通常指在创建 Pod 的沙盒环境时发生了问题。在 Kubernetes 中,"沙盒"通常是指容器运行时的环境,这个环境为容器提供了隔离和资源控制。该错误表明在设置这个基础环境时遇到了障碍。常见原因网络问题:创建 Pod 沙盒时,可能会因为网络配置或网络插件问题导致失败。容器运行时问题:容器运行时(如 Docker、containerd)可能遇到内部错误或配置问题。资源不足:节点上的 CPU、内存或存储资源不足,无法满足 Pod 的需求。系统错误:底层系统(如操作系统、内核)的问题可能导致无法正常创建沙盒。安全策略限制:如 PodSecurityPolicy 或其他安全框架设置的限制导致 Pod 无法创建。Kubernetes 组件错误:Kubernetes 自身的组件(如 kubelet 或 API 服务器)存在问题或配置错误。处理方式检查网络配置: 确认集群的网络插件(如 Calico、Flannel)正常运行。 检查 Pod 的网络策略或相关的网络设置是否正确。检查容器运行时: 确认容器运行时服务(如 Docker)正在运行并且健康。 检查容器运行时的日志,了解可能的错误信息。检查节点资源: 使用 kubectl describe node <node-name> 检查节点的资源使用情况。 确认节点上有足够的 CPU、内存和存储资源可供 Pod 使用。检查系统日志和状态: 查看节点上的系统日志(如 /var/log/messages、/var/log/syslog),找寻可能的错误信息。 确认操作系统和内核状态正常,没有出现相关的错误或故障。检查安全策略: 如果你的集群中启用了 PodSecurityPolicy 或其他安全框架,请检查相关策略是否阻止了 Pod 的创建。检查 Kubernetes 组件: 查看 kubelet 和 Kubernetes API 服务器的日志,寻找可能的错误信息。 确认 Kubernetes 的组件配置正确,无误配置或兼容性问题。重新调度或重启 Pod: 有时,简单的重新调度(删除后重新创建)Pod 或重启 kubelet 服务可以解决问题。13.ConfigPodSandboxErrorConfigPodSandboxError 在 Kubernetes 环境中出现,表明在配置 Pod 的沙盒环境时出错。沙盒环境是指为 Pod 创建的隔离环境,这包括网络、存储、安全设置等。此错误通常意味着在 Pod 初始化阶段,设置这些基本组件时出现了问题。常见原因网络配置问题:错误的网络配置或网络插件故障可能导致配置失败。容器运行时配置错误:容器运行时(如 Docker、containerd)的配置错误或故障。安全设置或策略错误:例如,错误的安全上下文、权限设置或 PodSecurityPolicy 配置错误。资源限制:节点的 CPU、内存限制或者其他资源限制可能导致配置失败。系统级错误:底层操作系统或 Kubernetes 自身的错误,如系统调用失败、内核问题等。处理方式检查网络配置: 审核集群的网络配置,确保网络插件(如 Calico、Flannel 等)运行正常。 检查相关的网络策略和设置,确保它们符合集群和 Pod 的需求。审核容器运行时配置: 确保容器运行时服务(如 Docker)正常工作。 检查容器运行时的配置文件和日志,寻找潜在的配置错误或警告。检查安全设置: 检查 Pod 定义中的安全上下文设置,确保它们正确无误。 如果使用 PodSecurityPolicy,确保相应的策略允许所需的配置。评估资源限制: 检查 Pod 所在节点的资源使用情况,包括 CPU、内存和磁盘空间。 适当调整 Pod 的资源请求和限制,确保其不超出节点可提供的范围。检查系统和 Kubernetes 组件: 查看底层主机的系统日志(如 /var/log/messages、/var/log/syslog)和内核日志(dmesg),找出可能的错误或告警。 确认 Kubernetes 组件(特别是 kubelet)运行正常,检查其日志以了解更多细节。14.KillPodSandboxErrorKillPodSandboxError 在 Kubernetes 环境中出现时,表明在尝试终止或清理 Pod 的沙盒环境(基础的隔离环境,包括网络、存储等)时发生了错误。这种错误通常出现在 Pod 正在被删除或重启的过程中。常见原因容器运行时问题:问题可能出现在底层的容器运行时(例如 Docker、containerd),例如进程卡死、响应超时或内部故障。资源释放问题:Pod 相关资源(如网络接口、存储卷)清理不彻底或失败。节点问题:节点硬件故障、操作系统问题、或是资源极度紧张(如 CPU、内存不足)可能导致操作失败。系统调用失败:底层的系统调用(如与网络或存储相关的调用)可能因权限不足、配置错误或系统问题而失败。Kubernetes 组件问题:kubelet 或 Kubernetes API 服务本身的故障或错误配置可能导致操作无法正确执行。处理方式检查容器运行时日志: 查看容器运行时(如 Docker、containerd)的日志,寻找任何错误或异常信息。 重启容器运行时服务可能有助于解决挂起或死锁问题。审查资源清理: 检查与 Pod 相关的网络接口和存储卷,确认它们是否已经被正确释放和清理。 如果发现资源泄露或清理不彻底,可能需要手动介入清理或调整自动清理流程。节点健康检查: 检查节点的 CPU、内存、磁盘空间等资源使用情况。 检查节点的系统日志(如 /var/log/messages、/var/log/syslog)和内核日志(dmesg)。系统配置和权限: 确保系统配置正确,特别是与网络和存储相关的配置。 检查是否有任何安全策略或权限设置阻碍了正常操作。Kubernetes 组件状态: 检查 kubelet 和 Kubernetes API 服务的状态和日志。 如果 kubelet 出现问题,考虑重启 kubelet 服务。15.SetupNetworkErrorSetupNetworkError 在 Kubernetes 环境中通常指 Pod 在设置网络(如分配 IP、设置网络路由等)过程中遇到错误。这可能导致 Pod 无法与其他 Pod 或服务正常通信。常见原因网络插件故障:如果使用的 CNI(容器网络接口)插件出现问题或配置错误,可能导致网络设置失败。IP 地址耗尽:如果集群中可分配的 IP 地址耗尽,新的 Pod 将无法获得 IP 地址。主机网络问题:节点上的网络问题(如 DNS 问题、路由问题、网络接口问题)也会影响 Pod 网络。资源限制:例如,安全策略(如 SELinux)或网络策略可能阻止网络的正常配置。系统错误:底层操作系统或网络堆栈中的错误、驱动问题或硬件故障。处理方式检查 CNI 插件: 确保 CNI 插件正常运行并且配置正确。 检查 CNI 插件的日志以寻找任何错误或警告信息。IP 地址管理: 检查 IP 地址池,确保还有足够的 IP 地址可供分配。 如果 IP 地址耗尽,考虑清理未使用的 IP 或扩展地址池。节点网络状态: 检查涉及的节点上的网络配置,包括 DNS、路由和网络接口。 使用命令如 ip addr, ip route, nslookup 等检查网络状态。审查资源限制和安全策略: 检查是否有任何网络策略或安全策略(如 SELinux)影响 Pod 网络设置。 确保这些策略正确配置,允许所需的网络流量和操作。操作系统和硬件检查: 检查操作系统的日志和状态,查看是否有与网络相关的错误或警告。 如果怀疑是硬件问题,如网络适配器故障,检查相应的硬件状态和日志。16.TeardownNetworkErrorTeardownNetworkError 在 Kubernetes 中通常表示在拆除或清理 Pod 的网络设置时遇到了问题。这种错误发生在 Pod 生命周期的末尾,当 Pod 被删除或重启时,其网络配置需要被清理。常见原因CNI 插件问题:容器网络接口(CNI)插件可能因为内部错误或配置不当导致无法正确拆除网络。资源释放问题:IP 地址或其他网络资源可能没有被正确释放回网络池。节点通信问题:拆除网络时,如果节点间的通信存在问题,可能导致网络设置无法正确拆除。Pod 状态异常:如果 Pod 在拆除网络时处于非正常状态,可能会导致清理过程失败。权限不足:执行网络拆除操作的进程可能因权限不足无法执行必要的步骤。处理方式检查 CNI 插件日志: 检查 CNI 插件的日志文件以寻找相关的错误信息。 验证 CNI 插件是否正确安装和配置。资源释放检查: 检查 IP 地址和网络资源是否被正确释放。 在网络池中查看是否有僵尸 IP 地址或未正确清理的资源。节点间通信检查: 确保涉及的节点间可以互相通信。 使用网络诊断工具(如 ping、traceroute)检查节点间网络连接。检查 Pod 状态: 使用 kubectl get pods 和 kubectl describe pod <pod-name> 查看 Pod 的当前状态和事件日志。 如果 Pod 处于异常状态,尝试解决这些问题后再进行网络拆除。权限检查: 确保执行网络拆除的进程具有足够的权限。 检查与安全策略相关的设置,如 SELinux、AppArmor 等。———————————————— 版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。原文链接:https://blog.csdn.net/weixin_46660849/article/details/134110477
2024年-5月-21日
127 阅读
0 评论
技术
置顶
K8S工作节点运行kubectl命令报错的原因及解决办法
K8S工作节点运行kubectl命令报错:The connection to the server localhost:8080 was refused - did you specify the right host or port?。原因分析:这是因为kubectl命令需要使用kubernetes-admin来运行,而工作节点上如果没有配置好相关的权限是无法执行的。可以用kubectl config view 命令查看,如下图可以看出节点2上是没有权限执行的。解决办法:1、将主节点中的【/etc/kubernetes/admin.conf】文件拷贝到从节点1相同目录下。如图2、回到工作节点1上配置环境变量:echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile如图:3、加载配置信息,source ~/.bash_profile4、查验是否正常执行kubectl命令.
2023年-11月-25日
579 阅读
0 评论
技术
置顶
k8s新增用户并授权其可查看所有名称空间的pod的权限
本文记录了在k8s里新增用户并授权其可查看所有名称空间的pod的权限,当用户用此账号登陆后在k8s就只有查看Pods权限功能,而不能删除或者创建功能。一、ssl认证生成一个证书(1)生成一个私钥进入目录:cd /etc/kubernetes/pki/ 执行命令:(umask 077; openssl genrsa -out hiboy.key 2048)(2)生成一个证书请求openssl req -new -key hiboy.key -out hiboy.csr -subj "/CN=hiboy"(3)生成一个证书openssl x509 -req -in hiboy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out hiboy.crt -days 3650二、在k8s里新增加一个用户账号:hiboy(1)把hiboy这个用户添加到kubernetes集群中,可以用来认证apiserver的连接[root@ctdmaster1 pki]# kubectl config set-credentials hiboy --client-certificate=./hiboy.crt --client-key=./hiboy.key --embed-certs=true(2)在kubeconfig下新增加一个hiboy账号context信息kubectl config set-context hiboy@kubernetes --cluster=kubernetes --user=hiboy(3)创建一个集群角色(clusterrole)[root@ctdmaster1 ~]# vim hiboy-clusterrole.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: hiboy-get-podrules:apiGroups: [""]resources: ["pods"]verbs: ["get", "list", "watch"][root@ctdmaster1]# kubectl apply -f hiboy-clusterrole.yaml(4)创建一个clusterrolebinding[root@ctdmaster1]# kubectl create clusterrolebinding hiboy-get-pods --clusterrole=hiboy-get-pod --user=hiboy三、账号信息配置1、在系统添加一个hiboy的普通用户useradd hiboy #新增系统用户 hiboypasswd hiboy #设置hiboy登陆密码(hi135246)[root@ctdmaster1 ~]# useradd hiboy[root@ctdmaster1 ~]# passwd hiboy更改用户 hiboy 的密码 。新的 密码:重新输入新的 密码:passwd:所有的身份验证令牌已经成功更新。2、调整修改账号配置信息(不要直接修改root/.kube/config的信息,不然K8s会问题)复制一份k8s配置信息:cp -ar /root/.kube /tmp/修改/tmp/.kube/config文件,把kubernetes-admin和其他账号相关删除,只留hiboy用户并把current-context变成如下:current-context: hiboy@kubernetes3、把配置信息复制到hiboy目录下cp -ar /tmp/.kube/ /home/hiboy/chown -R hiboy.hiboy /home/hiboy/4、切换账号测试su - hiboykubectl get podskubectl get pods -n kube-system由上图可以,如果是新用户到hiboy登陆系统可以直接查到k8s里所有的pods信息,但是并不具备其他功能,如果需要其他权限也可以采取相类似的操作进行。
2023年-11月-18日
709 阅读
0 评论
技术
2023-11-16
DaemonSet学习
DaemonSet 确保全部(或者某些)节点上运行一个 Pod 的副本。 当有新节点加入集群时, 会为他们新增一个DaemonSet的Pod 。 当有节点从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。daemonset的控制器会监听kuberntes的daemonset对象、pod对象、node对象,这些被监听的对象之变动,就会触发syncLoop循环让kubernetes集群朝着daemonset对象描述的状态进行演进Daemonset典型的应用场景在集群的每个节点上运行存储,比如:glusterd 或 ceph。在每个节点上运行日志收集组件,比如:flunentd 、 logstash、filebeat等。在每个节点上运行监控组件,比如:Prometheus、 Node Exporter 、collectd等。DaemonSet使用案例:部署日志收集组件fluentd把fluentd-2-5-1.tar.gz上传到ctdmaster1和ctdnode1和ctdnode2上,解压[root@ctdmaster1 ds]# ctr -n=k8s.io images import fluentd_2_5_1.tar.gz[root@ctdnode1 ~]# ctr -n=k8s.io images import fluentd_2_5_1.tar.gz[root@ctdnode2 ~]# ctr -n=k8s.io images import fluentd_2_5_1.tar.gz创建yaml资源配置文件[root@ctdmaster1 ds]# vim daemonset.yamlapiVersion: apps/v1kind: DaemonSetmetadata:name: fluentd-elasticsearchnamespace: kube-systemlabels:k8s-app: fluentd-loggingspec:selector:matchLabels:name: fluentd-elasticsearchtemplate:metadata:name: fluentdlabels:name: fluentd-elasticsearchspec:tolerations:- key: node-role.kubernetes.io/master # effect: NoSchedule - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule - key: node-role.kubernetes.io/master operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch image: xianchao/fluentd:v2.5.1 imagePullPolicy: IfNotPresent resources: limits: memory: 200Mi requests: cpu: '1' memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers保存退出,执行:[root@ctdmaster1 ds]# kubectl apply -f daemonset.yaml
2023年-11月-16日
361 阅读
0 评论
技术
置顶
创建Service资源(CLUSTER ip类型)实例记录
准备工作:把实验镜像包nginx.tar.gz上传到分节点ctdnode1和ctdnode2上,并导入镜像节点1: [root@ctdnode1 ~]# ctr -n=k8s.io images import nginx.tar.gz节点2: [root@ctdnode2 ~]# ctr -n=k8s.io images import nginx.tar.gz1、创建后端pod资源(使用准备好的nginx镜像)1)编写yaml文件:控制节点:[root@ctdmaster1 svc]# vim pod_test.yaml代码如下:apiVersion: apps/v1kind: Deploymentmetadata: name: my-nginxspec: selector: matchLabels: run: my-nginx replicas: 2 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / livenessProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / readinessProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: /2)执行命令运行pod资源:控制节点: [root@ctdmaster1 svc]# kubectl apply -f pod_test.yaml 3)、查看运行情况:kubectl get pods -l run=my-nginx -o wide4)请求Pod资源测试目前 Pod资源的应用已经运行起来,但是仅限于集群内,外部无法访问,这里就需要创建Service资源作代理,将外部的访问请求转发到Pod上。(需要注意的是,pod虽然定义了容器端口,但是不会使用调度到该节点上的80端口,也不会使用任何特定的NAT规则去路由流量到Pod上。 这意味着可以在同一个节点上运行多个 Pod,使用相同的容器端口,并且可以从集群中任何其他的Pod或节点上使用IP的方式访问到它们。)2、创建service,做一个好代理。service的工作主要是通过endpoint与selector协同工作实现,由selector选择出pod的ip地址和端口号,然后记录在endpoint中,当有请求访问到service的ip地址时,就会从endpoint中选择出一个ip地址和端口号,然后将请求重定向至对应的pod中,具体会把请求代理到哪个pod,那就是kube-proxy的轮询来实现的。service不会直接到pod,service是直接到endpoint资源,就是地址加端口,再由endpoint再关联到pod。1)创建Service资源yaml文件,控制节点:[root@ctdmaster1 svc]# vim service_test.yamlapiVersion: v1kind: Servicemetadata: name: my-nginx labels: run: my-nginxspec: type: ClusterIP ports: - port: 80 protocol: TCP targetPort: 80 selector: run: my-nginx我们创建一个 Service,具有标签run=my-nginx的Pod,目标TCP端口 80,并且开放一个抽象的Service端口(targetPort:容器接收流量的端口;port:抽象的 Service 端口,可以使任何其它 Pod访问该 Service 的端口)2)、保存退出生,运行Service资源, [root@ctdmaster1 svc]# kubectl apply -f service_test.yaml3)、查看运行情况:[root@ctdmaster1 svc]# kubectl get svc -l run=my-nginxService资源已经运行正常,集群IP地址是:10.97.128.704)、请求Service,测试结果:curl 10.97.128.70由上图可以看到,访问Service的IP请求到的资源跟之前请求pod节点上的资源,得到的结果是一样的。我们测试下,删除一个pod资源,请求Service看看访问结果有没有变。如下图:注意:上面的10.97.128.70:80地址只能是在集群(因为定义的是CLUSTER-IP类型)内部可以访问,在外部还是无法访问,也就是想要通过浏览器访问,那么是访问不通的,如果想要在k8s集群之外访问,是需要把service type类型改成nodePort。最后,有关Service域名其实Service只要创建完成,我们就可以直接解析它的服务名,每一个服务创建完成后都会在集群dns中动态添加一个资源记录,添加完成后我们就可以解析了,资源记录格式是:SVC_NAME.NS_NAME.DOMAIN.LTD.服务名.命名空间.域名后缀集群默认的域名后缀是svc.cluster.local.就像我们上面创建的my-nginx这个服务,它的完整名称解析就是my-nginx.default.svc.cluster.local这个记录好像只有pod内部可以访问,外部无法访问。大家思考下,是不是这样呢?
2023年-11月-6日
268 阅读
0 评论
技术
2023-11-4
K8S的设计结构
K8S的设计结构大致可分为下列三大部分Client: 属于用户触发请求的客户端,即Kubectl, 用户的各种触发的命令就是通过kuberctl统一封装后进行命令触发的Master:用于处理用户触发的请求,进行处理决策,Worker:命令真正的执行者,读取etcd的结果将数据最终执行K8S设计结构图ClientKubectl: 是k8s 的client,也是一般RD 最常用的操作方式之一,很多K8S的使用者主要就是通过kubectl跟K8S打交道。UI:Dashboard 也是一个独立服务,默认可以不需要,这个服务本身可以通过Kubectl部署在k8s上对外提供服务。MasterApiServer:Master 通信的入口, Client 和 Worker 之前同行ETCD:Master中唯一的决策结果的存储Controller Manager:里面保存各种controllerScheduler:执行实例资源的选择调度决策, 选择出合适的Worker节点来运行服务的Pod,真正的部署操作由Kubelet来执行WorkerKubelet:直接通过ApiServer的watch接口读取原始数据结果KubeProxy:网络请求通过Kubeproxy实现服务接口的转发,作为普通服务的命名管理Pod:将容器、网络和存储单元打包在一起,是服务独立的部署单元。核心思路是高内聚Container:原始服务容器,容器与pod 的对应关系是一个Pod中包含多个容器,多个容器之间的服务可以互相访问核心理念:K8s 设计的核心理念最终概括为4大点: 声明式、显示接口、无入侵性 和 可移植性声明式:对比指令式,需求任何功能通过yml文件来描述自己的需求,最终由k8s调度满足显示接口:任何接口定义都属于显示定义,不存在私有接口,所以给业务CRD 自定义提供前提, 每个K8s 可以根据自己的需求和现有的功能实现自己的服务功能无入侵性:该特点就是说任何服务部署只要提前打包好docker 的image ,是不需要再做任何代码改造,就可以完成部署。可移植性:可移植性主要是强调对于有状态的服务,通过PersistentVolume 支持屏蔽底层的数据存储细节
2023年-11月-4日
343 阅读
0 评论
技术
2023-11-3
deployment运行demo代码
Deployment是kubernetes中最常用的资源对象,为ReplicaSet和Pod的创建提供了一种声明式的定义方法,在Deployment对象中描述一个期望的状态,Deployment控制器就会按照一定的控制速率把实际状态改成期望状态,通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器,通过ReplicaSet创建pod,删除Deployment控制器,也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性,例如滚动升级、金丝雀发布、蓝绿部署和回滚。扩展:声明式定义是指直接修改资源清单yaml文件,然后通过kubectl apply -f 资源清单yaml文件,就可以更改资源。apiVersion: apps/v1kind: Deploymentmetadata: name: myapp-v1spec: replicas: 3 selector: matchLabels: app: myapp version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / livenessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / readinessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: /
2023年-11月-3日
373 阅读
0 评论
技术
置顶
kubernetes的查询操作命令
1、kubectl get all -o wide -A 【查询所有命名空间下常用资源】缺点:这种方法 kubectl get all 其实查询出来不是全部资源,仅仅是常用资源,仅仅是 service - deployment/statefulset/daemonset/job/cronjob - replicaset - pod 这个绑定链资源,还有 rbac 的 role rolebinding,配置文件 configmap secrets,服务账号 serviceAccount ,service与pod的绑定endpoints都没有查询出来2、kubectl api-versions 【查看所有apiVersion版本】3、kubectl api-resources 【查看所有资源类型】4、kubectl api-resources --verbs=list --namespaced -o name5、kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -A #查询所有命名空间下的所有资源
2023年-11月-2日
360 阅读
0 评论
技术
2023-11-1
关于名字空间(Namespace)
在 Kubernetes 中,名字空间(Namespace) 提供一种机制,将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一,但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象, (例如 Deployment、Service 等),这种作用域对集群范围的对象 (例如 StorageClass、Node、PersistentVolume 等)不适用。名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的,但不能跨名字空间。 名字空间不能相互嵌套,每个 Kubernetes 资源只能在一个名字空间中。名字空间是在多个用户之间划分集群资源的一种方法,而当名字空间中存在一个 ResourceQuota 对象时,对于该名字空间而言,资源配额就是开启的。当名字空间资源配额开启时,在空间里创建的Pod或者应用资源时必须必须设置资源限额,否则创建失败。Kubernetes 初始化启动时会自动创建四个名字空间:1、default:Kubernetes 包含这个名字空间,以便于你无需创建新的名字空间即可开始使用新集群。2、kube-node-lease:该名字空间包含用于与各个节点关联的 Lease(租约)对象。 节点租约允许 kubelet 发送心跳, 由此控制面能够检测到节点故障。3、kube-public:所有的客户端(包括未经身份验证的客户端)都可以读取该名字空间。 该名字空间主要预留为集群使用,以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。4、kube-system:该名字空间用于 Kubernetes 系统创建的对象有关名字空间的常用命令:1、创建名字空间kubectl create ns test2、获取当前名字空间列表kubectl get namespace/ns[root@ctdmaster1 ~]# kubectl get namespaceNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11dtest Active 11d3、删除名字空间kubectl delete namespaces 名字空间名此命令会删除名字空间下的 所有内容,谨慎操作 ![root@ctdmaster1 ~]# kubectl get nsNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11dtest Active 11d[root@ctdmaster1 ~]# kubectl get pods -n testNAME READY STATUS RESTARTS AGEpod-test 1/1 Running 0 158m[root@ctdmaster1 ~]# kubectl delete ns testnamespace "test" deleted[root@ctdmaster1 ~]# kubectl get pods -n testNo resources found in test namespace.[root@ctdmaster1 ~]# kubectl get nsNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11d 4、分析名字空间详细信息kubectl describe namespaces [root@ctdmaster1 ~]# kubectl describe ns testName: testLabels: kubernetes.io/metadata.name=testAnnotations: <none>Status: ActiveNo resource quota.No LimitRange resource.5、创建资源配额[root@ctdmaster1 ~]# vim namespace-quota.yaml #以下为资源配额内容apiVersion: v1kind: ResourceQuotametadata: name: mem-cpu-quota namespace: testspec: hard: requests.cpu: "2" requests.memory: 2Gi limits.cpu: "4" limits.memory: 4Gi执行命令:[root@ctdmaster1 ~]# kubectl apply -f namespace-quota.yaml 查看名字空间配额[root@ctdmaster1 ~]# kubectl describe ns testName: testLabels: kubernetes.io/metadata.name=testAnnotations: <none>Status: ActiveResource Quotas Name: mem-cpu-quota Resource Used Hard -------- --- --- limits.cpu 0 4 limits.memory 0 4Gi requests.cpu 0 2 requests.memory 0 2GiNo LimitRange resource.最后需要注意的是 kubernetes 资源(例如 Pod、Service、副本控制器等)都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中,而且底层资源, 例如节点和持久化卷不属于任何名字空间。查看哪些 Kubernetes 资源在名字空间中,哪些不在名字空间中:# 位于名字空间中的资源kubectl api-resources --namespaced=true 不在名字空间中的资源kubectl api-resources --namespaced=false
2023年-11月-1日
237 阅读
0 评论
技术
2023-10-28
k8s 中的三种容器探测方法
k8s 中的三种容器探测方法:启动探测、存活探测、就绪探测1、启动探测 startupProbe:探测容器中的应用是否已经启动。如果提供了启动探测(startup probe),则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet 将杀死容器,容器服从其重启策略进行重启。如果容器没有提供启动探测,则默认状态为成功Success。2、存活探测 livenessprobe:用指定的方式(exec、tcp、http)检测pod中的容器是否正常运行,如果检测失败,则认为容器不健康,那么Kubelet将根据Pod中设置的 restartPolicy策略来判断Pod 是否要进行重启操作,如果容器配置中没有配置 livenessProbe,Kubelet 将认为存活探针探测一直为success(成功)状态。3、就绪探测 readnessprobe:就绪性探针,用于检测容器中的应用是否可以接受请求,当探测成功后才使Pod对外提供网络访问,将容器标记为就绪状态,可以加到pod前端负载,如果探测失败,则将容器标记为未就绪状态,会把pod从前端负载移除。我们可以自定义在pod启动时是否执行这些检测,如果不设置,则检测结果均默认为通过,如果设置,则顺序为startupProbe>readinessProbe和livenessProbe,其中readinessProbe和livenessProbe是并发关系,官方文档是是这样描述的:Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe以上三种探测方法都支持下面三种探针:1、exec:在容器中执行指定的命令,如果执行成功,退出码为 0 则探测成功。2、TCPSocket:通过容器的 IP 地址和端口号执行 TCP 检 查,如果能够建立 TCP 连接,则表明容器健康。3、HTTPGet:通过容器的IP地址、端口号及路径调用 HTTP Get方法,如果响应的状态码大于等于200且小于400,则认为容器健康通常探针探测结果有以下值:1、Success:表示通过检测。2、Failure:表示未通过检测。3、Unknown:表示检测没有正常进行。Pod探针相关的属性:探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为initialDelaySeconds:容器启动后要等待多少秒后探针开始工作,单位“秒”,默认是 0 秒,最小值是 0periodSeconds: 执行探测的时间间隔(单位是秒),默认为 10s,单位“秒”,最小值是1timeoutSeconds: 探针执行检测请求后,等待响应的超时时间,默认为1,单位“秒”。successThreshold:连续探测几次成功,才认为探测成功,默认为 1,在 Liveness 探针中必须为1,最小值为1。failureThreshold: 探测失败的重试次数,重试一定次数后将认为失败,在 readiness 探针中,Pod会被标记为未就绪,默认为 3,最小值为 1两种探针区别:ReadinessProbe 和 livenessProbe 可以使用相同探测方式,只是对 Pod 的处置方式不同:readinessProbe 当检测失败后,将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。livenessProbe 当检测失败后,将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。
2023年-10月-28日
495 阅读
0 评论
技术
1
2