kubernetes故障处理手册（kubernetes解决什么问题）

本篇文章给大家谈谈kubernetes故障处理手册，以及kubernetes解决什么问题对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享kubernetes故障处理手册的知识，其中也会对kubernetes解决什么问题进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、kubernetes常见故障
• 2、资深架构师分享：1 天落地的 Kubernetes 容器化方案
• 3、[kubernetes] 已经被废弃的 tcp_tw_recycle, 运维的小伙伴看过来
• 4、2021-10-这一篇 K8S（Kubernetes）我觉得可以了解一下！！！28
• 5、kubernetes——StatefulSet详解

kubernetes常见故障

kubernetes常见故障

1. 节点CNI不可用，其它节点无法连接到故障节点的Pod

2. Subpath方式挂载的Configmap，特定条件下出现Pod无限重启的问题

3. 集群DNS服务器无法通过上游DNS解析外部名称

4. 节点假死，但是持有的Ceph RBD的Watcher不释放，导致有状态服务的Pod调度走后仍然无法启动

5. 误删Etcd数据、持久卷

有四个有用的命令可以对Pod进行故障排除：

kubectl logs 有助于检索Pod容器的日志

kubectl describe pod 检索与Pod相关的事件列表很有用

kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义

kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用

常见Pod错误

Pod可能会出现启动和运行时错误。

启动错误包括：

ImagePullBackoff

ImageInspectError

ErrImagePull

ErrImageNeverPull

RegistryUnavailable

InvalidImageName

运行时错误包括：

CrashLoopBackOff

RunContainerError

KillContainerError

VerifyNonRootError

RunInitContainerError

CreatePodSandboxError

ConfigPodSandboxError

KillPodSandboxError

SetupNetworkError

TeardownNetworkError

有些错误比其他错误更常见。

以下是最常见的错误列表以及如何修复它们的方法。

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。

共有三个可能的原因：

镜像名称无效-例如，你拼错了名称，或者image不存在

你为image指定了不存在的标签

你尝试检索的image属于一个私有registry，而Kubernetes没有凭据可以访问它

前两种情况可以通过更正image名称和标记来解决。

针对第三种情况，你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。

官方文档中有一个有关如何实现此目标的示例。

CrashLoopBackOff

如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。

通常，在以下情况下容器无法启动：

应用程序中存在错误，导致无法启动

你未正确配置容器

Liveness探针失败太多次

你应该尝试从该容器中检索日志以调查其失败的原因。

如果由于容器重新启动太快而看不到日志，则可以使用以下命令：

$ kubectl logs <pod-name --previous 

这个命令打印前一个容器的错误消息。

RunContainerError

当容器无法启动时，出现此错误。

甚至在容器内的应用程序启动之前。

该问题通常是由于配置错误，例如：

挂载不存在的卷，例如ConfigMap或Secrets

将只读卷安装为可读写

你应该使用kubectl describe pod 命令收集和分析错误。

处于Pending状态的Pod

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

为什么？

假设你的调度程序组件运行良好，可能的原因如下：

集群没有足够的资源（例如CPU和内存）来运行Pod

当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额

该Pod绑定到一个处于pending状态的 PersistentVolumeClaim

最好的选择是检查kubectl describe命令输出的“事件”部分内容：

$ kubectl describe pod <pod name 

对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志：

$ kubectl get events --sort-by=.metadata.creationTimestamp 

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready)，则表示readiness就绪探针失败。

当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。

就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。

2. 服务的故障排除

如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。

service旨在根据流量的标签将流量路由到Pod。

因此，你应该检查的第一件事是服务关联了多少个Pod。

你可以通过检查服务中的端点(endpoint)来做到这一点：

$ kubectl describe service <service-name | grep Endpoints 

端点是一对，并且在服务（至少）以Pod为目标时，应该至少有一个端点。

如果“端点”部分为空，则有两种解释：

你没有运行带有正确标签的Pod（提示：你应检查自己是否在正确的命名空间中）

service的selector标签上有错字

如果你看到端点列表，但仍然无法访问你的应用程序，则targetPort可能是你服务中的罪魁祸首。

你如何测试服务？

无论服务类型如何，你都可以使用kubectl port-forward来连接它：

$kubectl port-forward serviceservice-name 3000:80 

这里：

是服务的名称

3000 是你希望在计算机上打开的端口

80 是服务公开的端口

3.Ingress的故障排除

如果你已到达本节，则：

Pod正在运行并准备就绪

服务会将流量分配到Pod

但是你仍然看不到应用程序的响应。

这意味着最有可能是Ingress配置错误。

由于正在使用的Ingress控制器是集群中的第三方组件，因此有不同的调试技术，具体取决于Ingress控制器的类型。

但是在深入研究Ingress专用工具之前，你可以用一些简单的方法进行检查。

Ingress使用serviceName和servicePort连接到服务。

你应该检查这些配置是否正确。

你可以通过下面命令检查Ingress配置是否正确：

$kubectl describe ingress <ingress-name 

如果backend一列为空，则配置中必然有一个错误。

如果你可以在“backend”列中看到端点，但是仍然无法访问该应用程序，则可能是以下问题：

你如何将Ingress暴露于公共互联网

你如何将集群暴露于公共互联网

你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。

首先，获取你的Ingress控制器Pod（可以位于其他名称空间中）：

$ kubectl get pods --all-namespaces 

NAMESPACE NAME READY STATUS 

kube-system coredns-5644d7b6d9-jn7cq 1/1 Running 

kube-system etcd-minikube 1/1 Running 

kube-system kube-apiserver-minikube 1/1 Running 

kube-system kube-controller-manager-minikube 1/1 Running 

kube-system kube-proxy-zvf2h 1/1 Running 

kube-system kube-scheduler-minikube 1/1 Running 

kube-system nginx-ingress-controller-6fc5bcc 1/1 Running 

描述它以检索端口：

# kubectl describe pod nginx-ingress-controller-6fc5bcc 

--namespace kube-system \ 

| grep Ports 

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system 

此时，每次你访问计算机上的端口3000时，请求都会转发到Pod上的端口80。

现在可以用吗？

如果可行，则问题出在基础架构中。你应该调查流量如何路由到你的集群。

如果不起作用，则问题出在Ingress控制器中。你应该调试Ingress。

如果仍然无法使Ingress控制器正常工作，则应开始对其进行调试。

目前有许多不同版本的Ingress控制器。

热门选项包括Nginx，HAProxy，Traefik等。

你应该查阅Ingress控制器的文档以查找故障排除指南。

由于Ingress Nginx是最受欢迎的Ingress控制器，因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。

调试Ingress Nginx

Ingress-nginx项目有一个Kubectl的官方插件。

你可以用kubectl ingress-nginx来：

检查日志，后端，证书等。

连接到ingress

检查当前配置

你应该尝试的三个命令是：

kubectl ingress-nginx lint，它会检查 nginx.conf

kubectl ingress-nginx backend，以检查后端（类似于kubectl describe ingress ）

kubectl ingress-nginx logs，查看日志

请注意，你可能需要为Ingress控制器指定正确的名称空间–namespace 。

------------------------------------------------------------------------------------------------------

kubernetes之故障排查和节点维护(二)

系列目录

案例现场:

测试环境集群本来正常,突然间歇性地出现服务不能正常访问,过一会儿刷新页面又可以正常访问了.进入到服务所在的pod查看输出日志并没有发现异常.使用kubectl get node命令正好发现一个节点是NotReady状态

为了方便观察,使用kubectl get node --watch来观测一段时间,发现k8s-node1节点不断的在Ready和NotReady状态之间切换(使用kubectl get node -o wide可以查看节点的ip信息).

进入到出现问题的节点,使用命令journalctl -f -u kubelet来查看kubelet的日志信息,把错误日志截出来一段搜索一下,发现问题和这个问题基本上是一样的,发现这个问题的时间和github上issue提出的时间是在同一天,也没有看到解决办法.但是基本能确定是因为集群中k8s-node1上的kubernetes版本不一致造成的(从上面截图上可以看到,这个节点的版本是1.14.1其它的都是1.13.1,是怎么升上来的不清楚,可能是其它同事误操作升级导致的)

搜索kubernetes NotReady查看了一些解决经验,很多都是重启docker,重启kubectl等,然后都解决不了问题.于是尝试重置这个节点.

从集群中删除Node

由于这个节点上运行着服务,直接删除掉节点会导致服务不可用.我们首先使用kubectl drain命令来驱逐这个节点上的所有pod

kubectl drain k8s-node1 --delete-local-data --force --ignore-daemonsets

以上命令中--ignore-daemonsets往往需要指定的,这是因为deamonset会忽略unschedulable标签(使用kubectl drain时会自动给节点打上不可调度标签),因此deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,这样就会成为死循环.因此这里忽略daemonset.

实际在使用kubectl drain时候,命令行一直被阻塞,等了很久还在被阻塞.使用kubectl get pod命令查看pod状态时.其中一个叫作busybox的pod一直处于Terminating状态. 使用kubectl delete pod busybox同样无法删除它.这时候可以使用命令kubectl delete pods busybox --grace-period=0 --force来强制马上删除pod.

这时候控制台阻塞状态结束.下面执行命令kubectl delete node k8s-node1来删除这个节点.然后我们重新安装kubelet,kubeadm和kubectl

卸载旧版本

如果是通过yum方式安装的,可以通过yum list installed|grep xxx形式来找到已安装的组件,然后删除它们.删除以后重新安装.

这里之所以要重新安装是因为版本升级成了较为新的版本,如果版本是一样的,其它的不确定因素导致节点不稳定,又找不到具体原因,则可以通过kubeadm reset来重置安装.

重置命令并不会重置设置的iptables规则和IPVS如果想要重置iptables,则需要执行以下命令:

iptables -F iptables -t nat -F iptables -t mangle -F iptables -X

如果想要重置IPVS,则需要执行以下命令:

ipvsadm -C

这里我能够基本确定是由于版本不一致导致的,因此我并不重置iptables和IPVS,仅仅是重装组件.

重新加入集群

重置完成以后,我们把删除掉的k8s-node1节点使用kubeadm join重新加入到集群中

如果忘记了主节点初始化时候生成的加入token,可以在主节点上执行kubeadm token create --print-join-command重新生成加入token,然后把生成的命令复制到要加入集群的节点上执行.

重新加入集群后,观察了一段时间,一直是Ready状态,感觉终于稳定了,但是同事又反馈部署服务时出现以下错误

Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "5159f7918d520aee74c5a08c8707f34b61bcf1c340bfc444125331034e1f57f6" network for pod "test-58f4789cb7-7nlk8": NetworkPlugin cni failed to set up pod "test-58f4789cb7-7nlk8_default" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.4.1/24

幸好有伟大的互联网,通过搜索,找到以下解决方案

由于这次启动以后初次部署pod就失败了,因此此节点上还没有运行的服务,我们不需要执行kubectl drain,可以直接把这个节点删除.然后执行以下命令

kubeadm reset

systemctl stop kubelet

systemctl stop docker

rm -rf /var/lib/cni/

rm -rf /var/lib/kubelet/*

rm -rf /etc/cni/

ifconfig cni0 down

ifconfig flannel.1 down

ifconfig docker0 down

ip link delete cni0

ip link delete flannel.1

systemctl start docker

完了以后重新加入集群.这次可以正常工作了.

-----------------------------------------------------------------

资深架构师分享：1 天落地的 Kubernetes 容器化方案

Kubernetes 是趋势

Kubernetes 是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

2016、2017年开始，各大互联网厂商就已经进行了各种容器化 + Kubernetes的尝试，各种实践证明 Kubernetes 越来越成熟。

Kubernetes 门槛高

然而，Kubernetes 在更大范围内落地的过程却困难重重，原因主要在于其过高的学习门槛：

• 基础知识要求多，Linux、网络、Docker等；

• 集群安装管理复杂；

• Kubernetes 的配置文件 YAML 冗长，对象类型繁多、关联关系复杂

Kuboard 助力

Kuboard 从以下几方面解决 Kubernetes 落地的难题：

Kubernetes 安装手册

通过对 Kubernetes 安装步骤的反复研究，提供了精简的 Kubernetes 安装手册，并且听取网友实际安装过程中的反馈，多次修改和优化，逐渐形成经过检验的、简洁的 Kubernetes 安装手册。

图形化管理界面

提炼 Kubernetes 各核心概念之间的关系，帮助用户理解如何配置 Kubernetes，并以此为依据设计了 Kuboard 工作负载编辑器。使用 Kuboard，用户无需手工编写和维护冗长的 YAML 文件，配合 Kuboard 提供的其他辅助手段，完全通过图形界面就可以实现微服务的部署和维护。

Spring Cloud 微服务部署实战案例

Kuboard 提供 Spring Cloud 在 Kubernetes 上部署的实战案例分析，手把手帮助技术团队完成 Spring Cloud 微服务在 Kubernetes 上的部署和维护。

免费自助

这么好的东西卖多少钱？您完全无需为了使用此方案而进入漫长的商务谈判、内部审批流程。

使用 https://kuboard.cn 网站上提供的任何文档、资源、方案、软件 完全免费 ，已经有许多技术团队参考这些资料，结合其已有经验，顺利地完成 Kubernetes + 微服务的落地交付。碰到问题时，您也可以通过 Kuboard 社群获得支持， 私信回复“社群”可以免费获取技术支持跟学习资料。

[kubernetes] 已经被废弃的 tcp_tw_recycle, 运维的小伙伴看过来

最近准备自己动手部署测试kubernetes集群，注备写一个 hands on 的手册。突发奇想将 centos 原有的内核从3.10更新到了4.14版本，并执行一些常规的优化操作。没有想到在修改了 sysctl.conf 里面的一些参数，希望能对新的 kubernetes 性能有所帮助。

sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory

纳尼，没有tcp_tw_recycle这个参数了？ 怎么回事。。。

net.ipv4.tcp_tw_reuse = 0  表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭

net.ipv4.tcp_tw_recycle = 0  表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭

net.ipv4.tcp_fin_timeout = 60  表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间（可改为30，一般来说FIN-WAIT-2的连接也极少）

好像上面3个内核调整参数，都是很多 Linux 运维工程师的标配了，怎么我一升级内核就不行了？ 自己狠下心来好好去的看了 kernel 的文档，Linux 从4.12内核版本开始移除了 tcp_tw_recycle 这个参数。 好嘛，小弟我手贱贱，升级到了4.14现在没有这个参数，只能硬着头皮去掉。

但是这个参数对 linux 系统回收大量 tcp timeout wait 有帮助， tcp_tw_recycle通常会和tcp_tw_reuse参数一起使用，用于解决服务器TIME_WAIT状态连接过多的问题 。 但是 kernel 为什么又要取消掉呢？ 

简单来说就是，Linux会丢弃所有来自远端的timestramp时间戳小于上次记录的时间戳(由同一个远端发送的)的任何数据包。也就是说要使用该选项，则必须保证数据包的时间戳是单调递增的。同时从4.10内核开始，官方修改了时间戳的生成机制，所以导致  tcp_tw_recycle 和新时间戳机制工作在一起不那么友好，同时  tcp_tw_recycle 帮助也不那么的大。

此处的时间戳并不是我们通常意义上面的绝对时间，而是一个相对时间。很多情况下，我们是没法保证时间戳单调递增的，比如业务服务器之前部署了NAT，LVS等情况。相信很多小伙伴上班的公司大概率实用实用各种公有云，而各种公有云的 LVS 网关都是 FullNAT 。所以可能导致在高并发的情况下，莫名其妙的 TCP 建联不是那么顺畅或者丢连接。

而这也是很多优化文章中并没有提及的一点，大部分文章都是简单的推荐将net.ipv4.tcp_tw_recycle设置为1，却忽略了该选项的局限性，最终造成严重的后果(比如我们之前就遇到过部署在nat后端的业务网站有的用户访问没有问题，但有的用户就是打不开网页)。

这次我们要关注的不是上半部分的 TCP 新建连接，而是下半部分的 TCP 断开连接。 别人老谈 TCP 3次握手，我就来谈 TCP 4次“挥手告别”。

在说 TCP 断开连接之前，我想先插入点内容。 就是 为什么要在 TCP 传输种引入 TIMEWAIT 这个概念。

第一个作用就是避免新连接接收到重复的数据包，由于使用了时间戳，重复的数据包会因为时间戳过期被丢弃。

第二个作用是确保远端不是处于LAST-ACK状态，如果ACK包丢失，远端没有成功获取到最后一个ACK包，则会重发FIN包。直到：

1.放弃(连接断开)

2.收到ACK包

3.收到RST包

如果FIN包被及时接收到，并且本地端仍然是TIME-WAIT状态，那ACK包会被发送，此时就是正常的四次挥手流程。

如果TIME-WAIT的条目已经被新连接所复用，则新连接的SYN包会被忽略掉，并且会收到FIN包的重传，本地会回复一个RST包(因为此时本地连接为SYN-SENT状态)，这会让远程端跳出LAST-ACK状态，最初的SYN包也会在1秒后重新发送，然后完成连接的建立，整个过程不会中断，只是有轻微的延迟。流程如下:
TIME_WAIT永远是出现在主动发送断开连接请求的一方(下文中我们称之为客户)， 划重点：这一点面试的时候经常会被问到。 嘿嘿，这个可以做为面试官的杀手锏，上图逻辑保证好多人不知道。（我咋这么坏呢。。。）

客户在收到服务器端发送的FIN(表示"我们也要断开连接了")后发送ACK报文，并且进入TIME_WAIT状态，等待2MSL(MaximumSegmentLifetime 最大报文生存时间)。对于Linux，字段为TCP_TIMEWAIT_LEN硬编码为30秒，对于Windows为2分钟(可自行调整)。

说到 TCP_TIMEWAIT_LEN 这个我就多啰嗦几句，很多资深运维小伙伴，在早起为了加快 tcp timeout 的回收时间，经常会修改这个内核头文件中定义的宏数据，然后重编译内核。 说实话确实有一些用处，至少早起阿里很多基础平台的运维就是这么干的，至于其他大厂不得而知，这个仁者见仁吧。

    确保 TCP 连接在各种情况下，都能正常的关闭。我们的网络 IP 协议本身就是尽力而为的传输，所有传输的可靠性都是靠 TCP 协议栈来完成的。假如当 TCP 自身传输信令的过程中也出现了一些异常呢？ 是不是我们 TCP 传输协议本身需要一定的容错机制。

又回到了上面说到的 IP 网络本身尽力而为的传输机制，并不保证数据包在底层传输的时候，接收方收到的数据包的数据顺序不一定是按照发送方的顺序，再加上数据传输延迟，就让上图的问题发生的情况成为了大概率事件。

TIME_WAIT占用的1分钟时间内，相同四元组(源地址，源端口，目标地址，目标端口)的连接无法创建，通常一个ip可以开启的端口为net.ipv4.ip_local_port_range指定的32768-61000，如果TIME_WAIT状态过多，会导致无法创建新连接。

这个占用资源并不是很多，可以不用担心。 （现在服务器内存真心多，不怕。 如果你实用的虚拟机，而且还是短链接巨多，内存分配不那么充足的情况下，还要节省成本， 那就要当心咯）

1.修改为长连接，代价较大，长连接对服务器性能有影响。

2.增加可用端口范围(修改net.ipv4.ip_local_port_range); 增加服务端口，比如采用80，81等多个端口提供服务; 增加客户端ip(适用于负载均衡，比如nginx，采用多个ip连接后端服务器); 增加服务端ip; 这些方式治标不治本，只能缓解问题。

3.将net.ipv4.tcp_max_tw_buckets设置为很小的值(默认是18000). 当TIME_WAIT连接数量达到给定的值时，所有的TIME_WAIT连接会被立刻清除，并打印警告信息。但这种粗暴的清理掉所有的连接，意味着有些连接并没有成功等待2MSL，就会造成通讯异常。

4.修改TCP_TIMEWAIT_LEN值，减少等待时间，但这个需要修改内核并重新编译。（这个之前提过，有某个大厂的小伙伴之前这么做的，有效果，但是有其他负面情况，我没有做完整的评估，自己斟酌实用）

5.打开tcp_tw_recycle和tcp_timestamps选项。

6.打开tcp_tw_reuse和tcp_timestamps选项。

注意，注意，注意，重要的事情说三遍。 5和6之间只能选择一个，不能同时打开。

tcp_tw_recycle 选项在4.10内核之前还只是不适用于NAT/LB的情况(其他情况下，我们也非常不推荐开启该选项)，但4.10内核后彻底没有了用武之地，并且在4.12内核中被移除.

tcp_tw_reuse 选项仍然可用。在服务器上面，启用该选项对于连入的TCP连接来说不起作用，但是对于客户端(比如服务器上面某个服务以客户端形式运行，比如nginx反向代理)等是一个可以考虑的方案。

修改TCP_TIMEWAIT_LEN是非常不建议的行为。

2021-10-这一篇 K8S（Kubernetes）我觉得可以了解一下！！！28

Kubernetes 是Google开源的分布式容器管理平台，是为了更方便的在服务器中管理我们的容器化应用。

Kubernetes 简称 K8S，为什么会有这个称号？因为K和S是 Kubernetes 首字母和尾字母，而K和S中间有八个字母，所以简称 K8S，加上 Kubernetes 比较绕口，所以一般使用简称 K8S。

Kubernetes 即是一款容器编排工具，也是一个全新的基于容器技术的分布式架构方案，在基于Docker的基础上，可以提供从 创建应用应用部署提供服务动态伸缩应用更新 一系列服务，提高了容器集群管理的便捷性。

大家可以先看一下，下面一张图，里面有我们的 mysql，redis，tomcat，nginx 等配置信息，如果我们想要安装里面的数据，我们需要一个一个手动安装，好像也可以，反正也就一个，虽然麻烦了一点，但也不耽误。

但是随着技术的发展和业务的需要，单台服务器已经不能满足我们日常的需要了，越来越多的公司，更多需要的是集群环境和多容器部署，那么如果还是一个一个去部署，运维恐怕要疯掉了，一天啥也不干就去部署机器了，有时候，可能因为某一个环节出错，要重新，那真的是吐血。。。。。，如下图所示：

如果我想要部署，以下几台机器：

如果要一个一个去部署，人都要傻掉了，这什么时候是个头，如果是某里巴的两万台机器，是不是要当场提交辞职信，所以 K8S 就是帮助我们来做这些事情的，方便我们对容器的管理和应用的自动化部署，减少重复劳动，并且能够自动化部署应用和故障自愈。

并且如果 K8S 对于微服务有很好的支持，并且一个微服务的副本可以跟着系统的负荷变化进行调整，K8S 内在的服务弹性扩容机制也能够很好的应对突发流量。

Docker-Compose 是用来管理容器的，类似用户容器管家，我们有N多台容器或者应用需要启动的时候，如果手动去操作，是非常耗费时间的，如果有了 Docker-Compose 只需要一个配置文件就可以帮我们搞定，但是 Docker-Compose 只能管理当前主机上的 Docker，不能去管理其他服务器上的服务。意思就是单机环境。

Docker Swarm 是由Docker 公司研发的一款用来管理集群上的Docker容器工具，弥补了 Docker-Compose 单节点的缺陷， Docker Swarm 可以帮助我们启动容器，监控容器的状态，如果容器服务挂掉会重新启动一个新的容器，保证正常的对外提供服务，也支持服务之间的负载均衡。而且这些东西 Docker-Compose 是不支持的，

Kubernetes 它本身的角色定位是和 Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，当然也要一些不一样的特点， Kubernetes 是谷歌自己的产品，经过大量的实践和宿主机的实验，非常的成熟，所以 Kubernetes 正在成为容器编排领域的领导者，其 可配置性、可靠性和社区的广大支持，从而超越了 Docker Swarm ，作为谷歌的开源项目，它和整个谷歌的云平台协调工作。

在下图中，是K8S的一个集群，在这个集群中包含三台宿主机，这里的每一个方块都是我们的物理虚拟机，通过这三个物理机，我们形成了一个完整的集群，从角色划分，可以分为两种

打一个比较形象的比喻，我们可以把Pod理解成一个豆荚，容器就是里面的豆子，是一个共生体。

Pod里面到底装的是什么？

具体怎么部署Pod里面的容器，是按照我们项目的特性和资源的分配进行合理选择的。

pause容器：

Pause容器 全称infrastucture container（又叫infra）基础容器，作为init pod存在，其他pod都会从pause 容器中fork出来，这个容器对于Pod来说是必备的
一个Pod中的应用容器共享同一个资源：

在上图中如果没有 pause容器 ，我们的Nginx和Ghost，Pod内的容器想要彼此通信的话，都需要使用自己的IP地址和端口，才可以彼此进行访问，如果有 pause容器 ，对于整个Pod来说，我们可以看做一个整体，也就是我们的Nginx和Ghost直接使用localhost就可以进行访问了，他们唯一不同的就只是端口，这里面可能看着觉得比较简单，但其实是使用了很多网络底层的东西才实现的，感兴趣的小伙伴可以自行了解一下。

在 Kubernetes 中，每个Pod都会被分配一个单独的IP地址，但是Pod和Pod之间，是无法直接进行交互的，如果想要进行网络通信，必须要通过另外一个组件才能交流，也就是我们的 Service

Service 是服务的意思，在K8S中 Service 主要工作就是将多个不同主机上的Pod，通过 Service 进行连通，让Pod和Pod之间可以正常的通信

我们可以把 Service 看做一个域名，而相同服务的Pod集群就是不同的ip地址， Service 是通过 Label Selector 来进行定义的。

使用NodePort提供外部访问，只需要在每个Node上打开一个主机的真实端口，这样就可以通过Node的客户端访问到内部的Service。

Label 一般以 kv的方式附件在各种对象上，Label 是一个说明性的标签，它有着很重要的作用，我们在部署容器的时候，在哪些Pod进行操作，都需要根据Label进行查找和筛选，我们可以理解Label是每一个Pod的别名，只有取了名称，作为K8S的Master主节点才能找到对应的Pod进行操作。

用户通过 Kubectl 提交一个创建 Replication Controller 请求，这个请求通过 API Server 写入 etcd 中，这个时候 Controller Manager 通过 API Server 的监听到了创建的命名，经过它认真仔细的分析以后，发现当前集群里面居然还没有对应的Pod实例，赶紧根据 Replication Controller 模板定义造一个Pod对象，再通 过Api Server 写到我们 etcd 里面

到下面，如果被 Scheduler 发现了，好家伙不告诉我？？？，无业游民，这家伙一看就不是一个好人啊，它就会立即运行一个复杂的调度流程，为这个新的Pod选一个可以落户的Node，总算有个身份了，真是让人操心，然后通过 API Server 将这个结果也写到etcd中，随后，我们的 Node 上运行的小管家 Kubelet 进程通过 API Server 检测到这个 新生的小宝宝——“Pod”，就会按照它，就会按照这个小宝宝的特性，启动这个Pod并任劳任怨的负责它的下半生，直到Pod的生命结束。

然后我们通过 Kubectl 提交一个新的映射到这个Pod的Service的创建请求， Controller Manager 会通过Label标签查询到相关联的Pod实例，生成Service的Endpoints的信息，并通过 API Server 写入到etcd中，接下来，所有 Node 上运行的Proxy进程通过 Api Server 查询并监听 Service对象 与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod的流量转发功能。

kube-proxy： 是一个代理，充当这多主机通信的代理人，前面我们讲过Service实现了跨主机、跨容器之间的网络通信，在技术上就是通过 kube-proxy 来实现的，service是在逻辑上对Pod进行了分组，底层是通过 kube-proxy 进行通信的

kubelet： 用于执行K8S的命令，也是K8S的核心命令，用于执行K8S的相关指令，负责当前Node节点上的Pod的创建、修改、监控、删除等生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里

etcd： 用于持久化存储集群中所有的资源对象，API Server提供了操作 etcd的封装接口API，这些API基本上都是对资源对象的操作和监听资源变化的接口

API Server ： 提供资源对象的操作入口，其他组件都需要通过它提供操作的API来操作资源数据，通过对相关的资源数据“全量查询”+ “变化监听”，可以实时的完成相关的业务功能。

Scheduler ： 调度器，负责Pod在集群节点中的调度分配。

Controller Manager： 集群内部管理控制中心，主要是实现 Kubernetes 集群的故障检测和恢复的自动化工作。比如Pod的复制和移除，Endpoints对象的创建和更新，Node的发现、管理和状态监控等等都是由 Controller Manager 完成。

到这里K8S的基本情况我们就讲解完毕了，有喜欢的小伙伴记得 点赞关注 ，相比如Docker来说K8S有着更成熟的功能，经过谷歌大量实践的产物，是一个比较成熟和完善的系统。

关于K8S大家有什么想要了解或者疑问的地方欢迎大家留言告诉我。

我是牧小农，一个卑微的打工人，如果觉得文中的内容对你有帮助，记得一键三连，你们的三连是小农最大的动力。

kubernetes——StatefulSet详解

RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet是什么？顾名思义，有状态的集合，管理所有有状态的服务，比如MySQL、MongoDB集群等。
StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必须要用到共享存储。

在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表。

除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：

接下来看一些示例，演示下上面所说的特性，以加深理解

通过该配置文件，可看出StatefulSet的三个组成部分：

创建：

看下这三个Pod创建过程：

根据volumeClaimTemplates自动创建的PVC

Statefulset名称为web 三个Pod副本: web-0，web-1,web-2，volumeClaimTemplates名称为：www，那么自动创建出来的PVC名称为www-web[0-2]，为每个Pod创建一个PVC。

匹配Pod name(网络标识)的模式为： (序号)，比如上面的示例：web-0，web-1，web-2。

StatefulSet为每个Pod副本创建了一个DNS域名，这个域名的格式为： $(podname).(headless server name)，也就意味着服务间是通过Pod域名来通信而非Pod IP，因为当Pod所在Node发生故障时，Pod会被飘移到其它Node上，Pod IP会发生变化，但是Pod域名不会有变化。

StatefulSet使用Headless服务来控制Pod的域名，这个域名的FQDN为： (namespace).svc.cluster.local，其中，“cluster.local”指的是集群的域名。

根据volumeClaimTemplates，为每个Pod创建一个pvc，pvc的命名规则匹配模式：( volumeClaimTemplates.name)-(pod_name )，比如上面的 volumeMounts.name=www ， Pod name=web-[0-2]，因此创建出来的PVC是www-web-0、www-web-1、www-web-2。

删除Pod不会删除其pvc，手动删除pvc将自动释放pv。
关于Cluster Domain、headless service名称、StatefulSet 名称如何影响StatefulSet的Pod的DNS域名的示例：

在v1.7以后，通过允许修改Pod排序策略，同时通过.spec.podManagementPolicy字段确保其身份的唯一性。

在Kubernetes 1.7及更高版本中，通过.spec.updateStrategy字段允许配置或禁用Pod、labels、source request/limits、annotations自动滚动更新功能。

StatefulSet控制器将删除并重新创建StatefulSet中的每个Pod。它将以Pod终止（从最大序数到最小序数）的顺序进行，一次更新每个Pod。在更新下一个Pod之前，必须等待这个Pod Running and Ready。

参考：
https://www.cnblogs.com/tylerzhou/p/11027559.html

https://www.cnblogs.com/buyicoding/p/12591259.html

关于kubernetes故障处理手册和kubernetes解决什么问题的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 kubernetes故障处理手册的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于kubernetes解决什么问题、kubernetes故障处理手册的信息别忘了在本站进行查找喔。