K8s 常见问题

朱雀 2022-09-04 06:53 218阅读 0赞

### ![fa2d2702a405bc7f8a7a740d24bf15a0.gif][] ###

### 1.k8s是什么？ ###

Kubenetes是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。

### 2.容器和主机部署应用的区别是什么？ ###

容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时也更应该注重容器的数据持久化问题。另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。

3.K8s架构的组成是什么

![1849b20b5f47f173be679cf92407d1e7.png][]

*  主节点主要用于暴露API，调度部署和节点的管理；
 *  计算节点运行一个容器运行环境，一般是docker环境（类似docker环境的还有rkt），同时运行一个K8s的代理（kubelet）用于和master通信。计算节点也会运行一些额外的组件，像记录日志，节点监控，服务发现等等。计算节点是k8s集群中真正工作的节点。

Master节点：

*  Kubectl：客户端命令行工具，作为整个K8s集群的操作入口；
 *  Api Server：在K8s架构中承担的是“桥梁”的角色，作为资源操作的唯一入口，它提供了认证、授权、访问控制、API注册和发现等机制。客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；
 *  Controller-manager：负责维护群集的状态，比如故障检测、自动扩展、滚动更新等；
 *  Scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的node节点上；
 *  Etcd：担任数据中心的角色，保存了整个群集的状态；

Node节点：

*  Kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，一般运行在所有的节点，是Node节点的代理，当Scheduler确定某个node上运行pod之后，会将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向master返回运行状态。（自动修复功能：如果某个节点中的容器宕机，它会尝试重启该容器，若重启无效，则会将该pod杀死，然后重新创建一个容器）；
 *  Kube-proxy：Service在逻辑上代表了后端的多个pod。负责为Service提供cluster内部的服务发现和负载均衡（外界通过Service访问pod提供的服务时，Service接收到的请求后就是通过kube-proxy来转发到pod上的）；
 *  container-runtime：是负责管理运行容器的软件，比如docker
 *  Pod：是k8s集群里面最小的单位。每个pod里边可以运行一个或多个container（容器），如果一个pod中有两个container，那么container的USR（用户）、MNT（挂载点）、PID（进程号）是相互隔离的，UTS（主机名和域名）、IPC（消息队列）、NET（网络栈）是相互共享的。

### 4.kubenetes针对pod资源对象的健康监测机制。 ###

K8s中对于pod资源对象的健康状态检测，提供了三类probe（探针）来执行对pod的健康监测：

1） livenessProbe探针

可以根据用户自定义规则来判定pod是否健康，如果livenessProbe探针探测到容器不健康，则kubelet会根据其重启策略来决定是否重启，初始探测状态为健康状态直到探测失败。如果一个容器不包含livenessProbe探针，则kubelet会认为容器的livenessProbe探针的返回值永远成功。

2） ReadinessProbe探针

同样是可以根据用户自定义规则来判断pod是否健康，如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功。初始探测为失败状态，直到探测成功后，将pod加入到service的endpoint列表中。

3） startupProbe探针

启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可。

探针检查支持以下参数设置：

*  initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
 *  periodSeconds：检查间隔，多久执行probe检查，默认为10s；
 *  timeoutSeconds：检查超时时长，探测应用timeout后为失败；
 *  successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

探针支持分探测方案：

1）.通过执行命令的方式来检查服务是否正常，比如使用cat命令查看pod中的某个重要配置文件是否存在，若存在，则表示pod健康。反之异常。

Exec探测方式的yaml文件语法如下：

spec:  
      containers:  
      - name: liveness  
        image: k8s.gcr.io/busybox  
        args:  
        - /bin/sh  
        - -c  
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600  
        livenessProbe:         #选择livenessProbe的探测机制  
          exec:                      #执行以下命令  
            command:  
            - cat  
            - /tmp/healthy  
          initialDelaySeconds: 5          #在容器运行五秒后开始探测  
          periodSeconds: 5               #每次探测的时间间隔为5秒

在上面的配置文件中，探测机制为在容器运行5秒后，每隔五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。

2）Httpget： 通过发送http/htps请求检查服务是否正常，返回的状态码为200-399则表示容器健康（注http get类似于命令curl -I）。

Httpget探测方式的yaml文件语法如下：

spec:  
      containers:  
      - name: liveness  
        image: k8s.gcr.io/liveness  
        livenessProbe:              #采用livenessProbe机制探测  
          httpGet:                  #采用httpget的方式  
        scheme:HTTP         #指定协议，也支持https  
            path: /healthz          #检测是否可以访问到网页根目录下的healthz网页文件  
            port: 8080              #监听端口是8080  
          initialDelaySeconds: 3     #容器运行3秒后开始探测  
          periodSeconds: 3                #探测频率为3秒

上述配置文件中，探测方式为项容器发送HTTP GET请求，请求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。

3）tcpSocket： 通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康，这种方式与HTTPget的探测机制有些类似，tcpsocket健康检查适用于TCP业务。

tcpSocket探测方式的yaml文件语法如下：

spec:  
      containers:  
      - name: goproxy  
        image: k8s.gcr.io/goproxy:0.1  
        ports:  
    - containerPort: 8080  
    #这里两种探测机制都用上了，都是为了和容器的8080端口建立TCP连接  
        readinessProbe:  
          tcpSocket:  
            port: 8080  
          initialDelaySeconds: 5  
          periodSeconds: 10  
        livenessProbe:  
          tcpSocket:  
            port: 8080  
          initialDelaySeconds: 15  
          periodSeconds: 20

在上述的yaml配置文件中，两类探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接容器的8080端口，如果探测成功，则该pod为健康，十秒后，kubelet将进行第二次连接。

除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败，则重启容器。

探针探测的结果有以下三种可能：

*  Success：Container通过了检查；
 *  Failure：Container没有通过检查；
 *  Unknown：没有执行检查，因此不采取任何措施（通常是我们没有定义探针检测，默认为成功）。

5.如何控制滚动更新过程

可以通过下面的命令查看到更新时可以控制的参数：

kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge：　此参数控制滚动更新过程，副本总数超过预期pod数量的上限。可以是百分比，也可以是具体的值。默认为1。

（上述参数的作用就是在更新过程中，值若为3，那么不管三七二一，先运行三个pod，用于替换旧的pod，以此类推）

maxUnavailable： 此参数控制滚动更新过程中，不可用的Pod的数量。

（这个值和上面的值没有任何关系，举个例子：我有十个pod，但是在更新的过程中，我允许这十个pod中最多有三个不可用，那么就将这个参数的值设置为3，在更新的过程中，只要不可用的pod数量小于或等于3，那么更新过程就不会停止）。

6.镜像下载策略是什么

可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释。

K8s的镜像下载策略有三种：Always、Never、IFNotPresent；

*  Always：镜像标签为latest时，总是从指定的仓库中获取镜像；
 *  Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；
 *  IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。
 *  默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是IfNotPresent。

7.image的状态有哪些

*  Running：Pod所需的容器已经被成功调度到某个节点，且已经成功运行，
 *  Pending：APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程
 *  Unknown：APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致。

8.pod的重启策略是什么？

可以通过命令“kubectl explain pod.spec”查看pod的重启策略。（restartPolicy字段）

*  Always：但凡pod对象终止就重启，此为默认策略。
 *  OnFailure：仅在pod对象出现错误时才重启

9.K8s中部署应用版本回滚的命令

kubectl apply -f httpd2-deploy1.yaml  --record      
\#运行yaml文件，并记录版本信息；

kubectl rollout history deployment httpd-devploy1      
\#查看该deployment的历史版本

kubectl rollout undo deployment httpd-devploy1 --to-revision=1        
\#执行回滚操作，指定回滚到版本1

10.标签和标签选择器的作用是什么？

标签：是当相同类型的资源对象越来越多的时候，为了更好的管理，可以按照标签将其分为一个组，为的是提升资源对象的管理效率。

标签选择器：就是标签的查询过滤条件。目前API支持两种标签选择器：

*  基于等值关系的，如：“=”、“”“==”、“！=”（注：“==”也是等于的意思，yaml文件中的matchLabels字段）；
 *  基于集合的，如：in、notin、exists（yaml文件中的matchExpressions字段）；

11.常用的标签分类有哪些？

标签分类是可以自定义的，但是为了能使他人可以达到一目了然的效果，一般会使用以下一些分类：

*  版本类标签（release）：stable（稳定版）、canary（金丝雀版本，可以将其称之为测试版中的测试版）、beta（测试版）；
 *  环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；
 *  应用类（app）：ui、as、pc、sc；
 *  架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；
 *  分区标签（partition）：customerA（客户A）、customerB（客户B）；
 *  品控级别（Track）：daily（每天）、weekly（每周）

12.查看标签的方式。

kubectl get pod --show-labels    \#查看pod，并且显示标签内容

kubectl get pod -L env,tier      \#显示资源对象标签的值

kubectl get pod -l env,tier      \#只显示符合键值资源对象的pod，而“-L”是显示所有的pod

13.添加、修改觉删除标签的命令

\#对pod标签的操作    
kubectl label pod label-pod abc=123     \#给名为label-pod的pod添加标签    
kubectl label pod label-pod abc=456 --overwrite      \#修改名为label-pod的标签    
kubectl label pod label-pod abc-             \#删除名为label-pod的标签    
kubectl get pod --show-labels    
  
\#对node节点的标签操作       
kubectl label nodes node01 disk=ssd      \#给节点node01添加disk标签    
kubectl label nodes node01 disk=sss –overwrite    \#修改节点node01的标签    
kubectl label nodes node01 disk-         \#删除节点node01的disk标签

14.DaemonSet资源对象的特性

DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。

15.Pod的生命周期有哪些状态？

*  Pending：表示pod已经被同意创建，正在等待kube-scheduler选择合适的节点创建，或者正在准备镜像；
 *  Running：表示pod中所有的容器已经被创建，并且至少有一个容器正在运行或者是正在启动或者是正在重启；
 *  Succeeded：表示所有容器已经成功终止，并且不会再启动；
 *  Failed：表示pod中所有容器都是非0（不正常）状态退出；
 *  Unknown：表示无法读取Pod状态，通常是kube-controller-manager无法与Pod通信。

16.创建一个Pod的流程是如何的？

![aa8046df8b6c70cd9a8d2a686faa90d5.png][]

*  客户端提交Pod的配置信息（可以是yaml文件定义好的信息）到kube-apiserver；
 *  Apiserver收到指令后，通知给controller-manager创建一个资源对象；
 *  Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中；
 *  Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发送到node节点上的kubelet组件上。
 *  Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行状况的信息存储到etcd数据中心。

17.删除一个Pod的流程是如何的？

Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作；

关闭流程如下：

*  pod从service的endpoint列表中被移除；
 *  如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
 *  进程被发送TERM信号（kill -14）
 *  当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）。

18.K8s的service是什么？

Pod每次重启或者重新部署，其IP地址都会产生变化，这使得pod间通信和pod与外部通信变得困难，这时候，就需要Service为pod提供一个固定的入口。

Service的Endpoint列表通常绑定了一组相同配置的pod，通过负载均衡的方式把外界请求分配到多个pod上。

19.k8s如何进服务注册？

Pod启动后会加载当前环境所有Service信息，以便不同Pod根据Service名进行通信。

20.K8s数据持久化的方式有哪些？

![2f2ca6f57aa870b0deb72a90669621e2.png][]

emptyDir是最基础的Volume类型，用于存储临时数据的简单空目录。如果Pod设置了emptyDir类型Volume，Pod被分配到Node上时候，会创建emptyDir，只要Pod运行在Node上，emptyDir都会存在（容器挂掉不会导致emptyDir丢失数据），但是如果Pod从Node上被删除（Pod被删除，或者Pod发生迁移），emptyDir也会被删除，并且永久丢失。

Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。这种数据持久化方式，运用场景不多，因为它增加了pod与节点之间的耦合。

![0bac562ac4c8da1d81fe512fe48f2f12.png][]

PersistentVolume (持久卷， 简称 PV)和Persistent VolumeClaim(持久卷声明，简称 PVC)使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，由K8s集群的使用者即服务的管理员来配置。

![73eff64c022ff9c107f54fd4c7e6ce71.png][]

END

精彩文章推荐

[从0开始轻松玩转k8s，助力企业实现智能化转型+世界500强实战项目汇总][0_k8s_500]

[k8s超详细解读][k8s]

[K8s 超详细总结！][K8s]

[Nginx如何限流？][Nginx]

[使用 root 用户执行Docker、K8s命令？No!][root _Docker_K8s_No]

[GitLab 持续集成][GitLab]

[使用k3s部署轻量Kubernetes集群快速教程][k3s_Kubernetes]

[K8S 常见面试题总结][K8S]

[两大容器管理平台，Kubernetes与OpenShift有什么区别？][Kubernetes_OpenShift]

[容器运行时Containerd基础][Containerd]

[基于Jenkins和k8s构建企业级DevOps容器云平台][Jenkins_k8s_DevOps]

[轻松快速地调整Kubernetes的CPU和内存][Kubernetes_CPU]

[2020年，值得收藏的50多种Kubernetes工具][2020_50_Kubernetes]

** Docker+k8s+DevOps+Istio+Rancher+CKA+k8s故障排查训练营：**

https://edu.51cto.com/topic/4735.html?qd=xglj

![7a6aa07946d304b7248d9f431c722da4.png][]

## 技术交流    ##

为了大家更快速的学习知识，掌握技术，随时沟通交流问题，特组建了技术交流群，大家在群里可以分享自己的技术栈，抛出日常问题，群里会有很多大佬及时解答的，这样我们就会结识很多志同道合的人，长按或者扫描下图二维码可加我微信，备注运维或者k8s或者devops即可进群，让我们共同的努力，向着美好的未来出发吧~~，**想要****免费获取****linux、k8s、DevOps、Openstack、Openshift、运维、开发、测试、架构师、Python、Go、面试文档、容器、岗位内推等资料也可进群获取****哈~~**

![b64208c9ee8f9b0808984e3f69ed5aff.png][]

**微信：** luckylucky421302

点亮，服务器10年不宕机![d5bf66874f23cd096852fcd06c0d79e3.gif][]

![e425ece408e2432c6c09b8f3be52f9e5.gif][] 点击**阅读****原****文** | 即刻学习

[fa2d2702a405bc7f8a7a740d24bf15a0.gif]: /images/20220829/5797317455aa4bb18da31eff91987257.png
[1849b20b5f47f173be679cf92407d1e7.png]: /images/20220829/1d622c13d90641a1b9341bfeca8ff658.png
[aa8046df8b6c70cd9a8d2a686faa90d5.png]: /images/20220829/de822da56f23416da0106fd5867d51ca.png
[2f2ca6f57aa870b0deb72a90669621e2.png]: /images/20220829/be5eb07b23f34245aebc061741f01ca2.png
[0bac562ac4c8da1d81fe512fe48f2f12.png]: /images/20220829/f9ec0d871f7d4f14867990deb67a6c4b.png
[73eff64c022ff9c107f54fd4c7e6ce71.png]: /images/20220829/4aa958bd1bfe446eb12a0ef1a0fa3a4b.png
[0_k8s_500]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6397f7cc141ee1f81d8393991e2a3d023280a52263b868b00b13a008934a9de8a4ee90e3ef&idx=1&mid=2247489762&scene=21&sn=dad10a59ae65f36179466d3b6c5aab52#wechat_redirect
[k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639629cc141f3fdc6a66be228477ffff9c3b8e3fa5419e591c646e436306285f2cdac19f83&idx=2&mid=2247489852&scene=21&sn=288dc83df6f0c68f91fb53216594a15e#wechat_redirect
[K8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639769cc141e7fbaf3a009cb148d31c5ea01952e934d1f85cb07b7dcfd14c0223deeb7334d&idx=2&mid=2247489660&scene=21&sn=90b834697b9cb8138c78d7a44627271d#wechat_redirect
[Nginx]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6398f4cc1411e2c532496da14fb64ce1f9847c1d6f295802686453b783119d4e5b604201bc&idx=2&mid=2247489505&scene=21&sn=a94e69e3bd93163f5e47783bd15a72c0#wechat_redirect
[root _Docker_K8s_No]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6398c4cc1411d22d16263ebce9d77775ab6a26455b3a9298cf621955cd54d79d4c9276046c&idx=2&mid=2247489489&scene=21&sn=db512312d25d183cefec1292285fceac#wechat_redirect
[GitLab]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639733cc141e25d556870782bf4f062f98a9eaeec1304503707973957b9eeb3db88639e80e&idx=2&mid=2247489574&scene=21&sn=3a2adab82877eb1ab95c629d74a2ba6a#wechat_redirect
[k3s_Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb63975bcc141e4dffe36433c774ce4baa00b0ed551062cc302fbd1aa40b6ec097d2979ec095&idx=1&mid=2247489614&scene=21&sn=1134326567a55bc81d6c46bac17d1ab5#wechat_redirect
[K8S]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb63975dcc141e4b71bc75d4ae50ee5b18d59c10bc60b382d7dc4539b2480a1378388805de98&idx=2&mid=2247489608&scene=21&sn=2ebcf492dc0196a94739abfad31308e9#wechat_redirect
[Kubernetes_OpenShift]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb63979bcc141e8d848165581e1bcd34772a7d4470346b21bca08ec2aab4c39d6406bbd33db2&idx=2&mid=2247489678&scene=21&sn=2f48bd49fa2f2dea1da2cd475f44d232#wechat_redirect
[Containerd]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6397dacc141eccbfe81e6e0aba506ef934bc004eef21b2e16d2beae55b90a66ebc5180100a&idx=2&mid=2247489743&scene=21&sn=23b58f4e98df39d45a6bee3dcaad95ea#wechat_redirect
[Jenkins_k8s_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6397e5cc141ef3e077bf3a81286caae7cb35895c9f27824c9edbf5823bb67d6588468e20ee&idx=1&mid=2247489776&scene=21&sn=85d2787df5213314737c23f9a798a769#wechat_redirect
[Kubernetes_CPU]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639633cc141f2554658a5a4010ec5e2868552edd4800168bcc33aa8f8f8ec7cb9471218b2b&idx=1&mid=2247489830&scene=21&sn=eba1d47c87b21236e8371f033d2329f8#wechat_redirect
[2020_50_Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb63965bcc141f4d899ed9300bed6737509504ac3f7b419eea11fb2afe4c81e5b15d6ab8485a&idx=1&mid=2247489870&scene=21&sn=c568abe4f7fb1cef7b1a5017f1a6694d#wechat_redirect
[7a6aa07946d304b7248d9f431c722da4.png]: /images/20220829/bdfdb425b21941e09d0e125a2eecd8ca.png
[b64208c9ee8f9b0808984e3f69ed5aff.png]: /images/20220829/220dc6adbda04b93b3fe64340f8071cf.png
[d5bf66874f23cd096852fcd06c0d79e3.gif]: /images/20220829/b41c40258259450b8e1d2328ea8983ee.png
[e425ece408e2432c6c09b8f3be52f9e5.gif]: /images/20220829/cdfff6d8d4a8420b801ab8e375e58126.png