k8s面试题大全，保姆级的攻略哦（二）
目录
三十六、pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？
三十七、标签及标签选择器是什么，如何使用？
三十八、service是如何与pod关联的？
三十九、service的域名解析格式、pod的域名解析格式
四十、service的类型有哪几种？
四十一、一个应用pod是如何发现service的，或者说，pod里面的容器用于是如何连接service的？
四十二、如何创建一个service代理外部的服务，或者换句话来说，在k8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?
四十三、service、endpoint、kube-proxy三种的关系是什么？
四十四、无头service和普通的service有什么区别，无头service使用场景是什么？
四十五、deployment怎么扩容或缩容？
四十六、deployment的更新升级策略有哪些？
四十七、deployment的滚动更新策略有两个特别主要的参数，解释一下它们是什么意思？
四十八、deployment更新的命令有哪些？
四十九、简述一下deployment的更新过程 （经常问）
五十、deployment的回滚使用什么命令
五十一、讲一下都有哪些存储卷，作用分别是什么?
五十二、pv的访问模式有哪几种
五十三、pv的回收策略有哪几种？
五十四、在pv的生命周期中，一般有几种状态
五十五、怎么使一个node脱离集群调度，比如要停机维护但又不能影响业务应用？
五十六、pv存储空间不足怎么扩容?
五十七、k8s生产中遇到什么特别影响深刻的问题吗，问题排查解决思路是怎么样的？（重点）
五十八、什么是Kubernetes的Service Account，它有什么用途？
五十九、Kubernetes如何管理持久化存储？
六十、Kubernetes如何实现访问控制和权限管理？
六十一、如何确保Kubernetes集群的安全性？
六十二、在Kubernetes中，你如何管理持久化存储？
六十三、描述Kubernetes的亲和性和反亲和性规则，并解释它们如何影响Pod的调度
六十四、Kubernetes中的Ingress是什么，它如何工作？
六十五、Kubernetes的自动伸缩（Autoscaling）是如何工作的？
六十七、Kubernetes中的DaemonSet是什么，它通常用于什么场景？
六十八、Kubernetes中的StatefulSet和Deployment有什么区别？
六十九、Kubernetes中的ConfigMap和Secret如何用于应用程序配置？
七十、Kubernetes中的准入控制器（Admission Controllers）是什么，它们如何影响集群的行为？
七十一、Kubernetes中的CNI是什么，它在集群中的作用是什么？
七十二、Kubernetes中的Ingress是什么？它如何与Service一起工作？
七十三、Kubernetes中的服务发现是如何工作的？
三十六、pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？
不会。
在pod中定义的command参数用于指定容器的启动命令列表，如果不指定，则默认使用Dockerfile打包时的启动命令，args参数用于容器的启动命令需要的参数列表；
特别说明：
kubernetes中的command、args其实是实现覆盖dockerfile中的ENTRYPOINT的功能的。当：
1、如果command和args均没有写，那么使用Dockerfile的配置；
2、如果command写了但args没写，那么Dockerfile默认的配置会被忽略，执行pod容器指定的command；
3、如果command没写但args写了，那么Dockerfile中的ENTRYPOINT的会被执行，使用当前args的参数；
4、如果command和args都写了，那么Dockerfile会被忽略，执行pod当前定义的command和args。
三十七、标签及标签选择器是什么，如何使用？
标签是键值对类型，标签可以附加到任何资源对象上，主要用于管理对象，查询和筛选。标签常被用于标签选择器的匹配度检查，从而完成资源筛选；一个资源可以定义一个或多个标签在其上面。
标签选择器，标签要与标签选择器结合在一起，标签选择器允许我们选择标记有特定标签的资源对象子集，如pod，并对这些特定标签的pod进行查询，删除等操作。
标签和标签选择器最重要的使用之一在于，在deployment中，在pod模板中定义pod的标签，然后在deployment定义标签选择器，这样就通过标签选择器来选择哪些pod是受其控制的，service也是通过标签选择器来关联哪些pod最后其服务后端pod。
三十八、service是如何与pod关联的？
答案：通过标签选择器。每一个由deployment创建的pod都带有标签，这样，service就可以定义标签选择器来关联哪些pod是作为其后端了，就是这样，service就与pod关联在一起了。
三十九、service的域名解析格式、pod的域名解析格式
service的DNS域名表示格式为<servicename>.<namespace>.svc.<clusterdomain>，servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local，一般的，我们不会去改k8s集群设置的域名后缀，同时，当pod要链接的svc处于pod当前命名空间时，可以省略<namespace>以及后面的.svc不写，这样，就可以有下面三种方式来表示svc的域名：
#查看k8s集群设置的域名后缀
grep -i clusterDomain /opt/kubernetes/config/kubelet-config.yml #二进制安装的k8s集群，可以这样查看
grep -i clusterDomain /etc/kubernetes/kubelet.conf #kubeadm安装的k8s集群,各个节点的kubelet.conf文件中的字段clusterDomain
grep -i clusterDomain /var/lib/kubelet/config.yaml #kubeadm安装的k8s集群,各个节点的config.yaml文件中的字段clusterDomain
kubectl -n kube-system get cm coredns -oyaml #coredns cm里面也可以看到
kubectl exec -it busybox -- cat /etc/resolv.conf #直接看pod里面的resolv.conf文件亦可
svc-nginx.default.svc.cluster.local #完整的写法
svc-nginx.default #带命名空间写法,省略了后面的.svc.<clusterdomain>
svc-nginx #如果pod与svc在同一个命名空间,可以将命名空间省略不写,换句话说链接的是当前命名空间的svc#于是,svc域名+svc的端口,我们就可以在pod里面访问svc对应的应用了,如下
wget http://svc-deployment-nginx.default.svc.cluster.local:80 #完整的写法
wget http://svc-deployment-nginx.default:80 #带命名空间写法
wget http://svc-deployment-nginx:80 #如果pod与svc在同一个命名空间,可以将命名空间省略不写
pod的DNS域名格式为：<pod-ip>.<namespace>.pod.<clusterdomain> ，其中，pod-ip需要使用-将ip之间的点替换掉，namespace为pod所在的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，如果没有改变k8s集群默认的域名后缀，则可以省略该后缀不写。除此之外，其他的均不可省略，这一点与svc域名有所不同。
演示如下：
#进入default命名空间的busybox pod里面，测试下载文件
kubectl -n default exec -it deployment-busybox-567674bd67-lmrgw -- sh
wget 10-244-166-167.helm.pod.cluster.local:80 #可以正常下载,这里下载的是helm命名空间里的IP为10.244.166.167的pod
wget 10-244-166-167.helm.pod:80 #可以正常下载,这里把k8s集群设置的域名后缀默认省略了
wget 10-244-166-143.default.pod:80 #可以正常下载,这里下载的是default命名空间里的IP为10.244.166.143的pod
wget 10-244-166-143.default:80 #报错了,错误写法,说明不能省略pod关键字
wget 10-244-166-143:80 #报错了,错误写法,说明不能省略命名空间和pod关键字
对于deployment、daemonsets等创建的无状态的pod，还还可以通过<pod-ip>.<deployment-name>.<namespace>.svc.<clusterdomain> 这样的域名访问。（这点存疑，一直测试失败，不指定是书中写错了还是什么）
对于StatefulSet创建的pod，statefulset.spec.serviceName字段解释如下：
[root@matser ~]# kubectl explain statefulset.spec.serviceName
KIND: StatefulSet
VERSION: apps/v1
FIELD: serviceName <string>
DESCRIPTION:serviceName is the name of the service that governs this StatefulSet. Thisservice must exist before the StatefulSet, and is responsible for thenetwork identity of the set. Pods get DNS/hostnames that follow thepattern: pod-specific-string.serviceName.default.svc.cluster.local where"pod-specific-string" is managed by the StatefulSet controller.
也就是说StatefulSet创建的pod，其pod的域名为：pod-specific-string.serviceName.default.svc.cluster.local，而pod-specific-string就是pod的名称。
例如：redis-sts-0.redis-svc.default.svc.cluster.local:6379,redis-sts-1.redis-svc.default.svc.cluster.local:6379,redis-sts-2.redis-svc.default.svc.cluster.local:6379,redis-sts-3.redis-svc.default.svc.cluster.local:6379,redis-sts-4.redis-svc.default.svc.cluster.local:6379,redis-sts-5.redis-svc.default.svc.cluster.local:6379，pod里面的后端应用程序就可以拿这串字符串去连接Redis集群了。
四十、service的类型有哪几种？
service的类型一般有4种，分别是：
ClusterIP：表示service仅供集群内部使用,默认值就是ClusterIP类型
NodePort：表示service可以对外访问应用,会在每个节点上暴露一个端口,这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了
LoadBalancer：表示service对外访问应用,这种类型的service是公有云环境下的service,此模式需要外部云厂商的支持,需要有一个公网IP地址
ExternalName：这种类型的service会把集群外部的服务引入集群内部,这样集群内直接访问service就可以间接的使用集群外部服务了
一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。
四十一、一个应用pod是如何发现service的，或者说，pod里面的容器用于是如何连接service的？
答：有两种方式，一种是通过环境变量，另一种是通过service的dns域名方式。
1、环境变量：当pod被创建之后，k8s系统会自动为容器注入集群内有效的service名称和端口号等信息为环境变量的形式，这样容器应用直接通过取环境变量值就能访问service了，如，每个pod都会自动注入了api-server的svc：curl http://${KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}
2、DNS方式：使用dns域名解析的前提是k8s集群内有DNS域名解析服务器，默认k8s中会有一个CoreDNS作为k8s集群的默认DNS服务器提供域名解析服务器；service的DNS域名表示格式为<servicename>.<namespace>.svc.<clusterdomain>，servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，这样容器应用直接通过service域名就能访问service了，如wget http://nginx-svc.default.svc.cluster.local:80，另外，service的port端口如果定义了名称，那么port也可以通过DNS进行解析，格式为：_<portname>._<protocol>.<servicename>.<namespace>.svc.<clusterdomain>
四十二、如何创建一个service代理外部的服务，或者换句话来说，在k8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?
答：可以通过创建一个没有标签选择器的service来代理集群外部的服务。
1、创建service时不指定selector标签选择器，但需要指定service的port端口、端口的name、端口协议等，这样创建出来的service因为没有指定标签选择器就不会自动创建endpoint；
2、手动创建一个与service同名的endpoint，endpoint中定义外部服务的IP和端口，endpoint的名称一定要与service的名称一样，端口协议也要一样，端口的name也要与service的端口的name一样，不然endpoint不能与service进行关联。
完成以上两步，k8s会自动将service和同名的endpoint进行关联，这样，k8s集群内的应用服务直接访问这个service就可以相当于访问外部的服务了。
四十三、service、endpoint、kube-proxy三种的关系是什么？
service：在kubernetes中，service是一种为一组功能相同的pod提供单一不变的接入点的资源。当service被建立时，service的IP和端口不会改变，这样外部的客户端（也可以是集群内部的客户端）通过service的IP和端口来建立链接，这些链接会被路由到提供该服务的任意一个pod上。通过这样的方式，客户端不需要知道每个单独提供服务的pod地址，这样pod就可以在集群中随时被创建或销毁。
endpoint：service维护一个叫endpoint的资源列表，endpoint资源对象保存着service关联的pod的ip和端口。从表面上看，当pod消失，service会在endpoint列表中剔除pod，当有新的pod加入，service就会将pod ip加入endpoint列表；但是正在底层的逻辑是，endpoint的这种自动剔除、添加、更新pod的地址其实底层是由endpoint controller控制的，endpoint controller负责监听service和对应的pod副本的变化，如果监听到service被删除，则删除和该service同名的endpoint对象，如果监听到新的service被创建或者修改，则根据该service信息获取得相关pod列表，然后创建或更新service对应的endpoint对象，如果监听到pod事件，则更新它所对应的service的endpoint对
kube-proxy：kube-proxy运行在node节点上，在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作，kube-proxy会监听api-server中从而获取service和endpoint的变化情况，创建并维护路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
四十四、无头service和普通的service有什么区别，无头service使用场景是什么？
答：无头service没有cluster ip，在定义service时将 service.spec.clusterIP：None，就表示创建的是无头service。
普通的service是用于为一组后端pod提供请求连接的负载均衡，让客户端能通过固定的service ip地址来访问pod，这类的pod是没有状态的，同时service还具有负载均衡和服务发现的功能。普通service跟我们平时使用的nginx反向代理很相似。
但是，试想这样一种情况，有6个redis pod ,它们相互之间要通信并要组成一个redis集群，不在需要所谓的service负载均衡，这时无头service就是派上用场了，无头service由于没有cluster ip
kube-proxy就不会处理它也就不会对它生成规则负载均衡，无头service直接绑定的是pod 的ip。无头service仍会有标签选择器，有标签选择器就会有endpoint资源。
使用场景：无头service一般用于有状态的应用场景，如Kaka集群、Redis集群等，这类pod之间需要相互通信相互组成集群，不在需要所谓的service负载均衡。
四十五、deployment怎么扩容或缩容？
答：直接修改pod副本数即可，可以通过下面的方式来修改pod副本数：
1、直接修改yaml文件的replicas字段数值，然后kubectl apply -f xxx.yaml来实现更新；
2、使用kubectl edit deployment xxx 修改replicas来实现在线更新；
3、使用kubectl scale --replicas=5 deployment/deployment-nginx命令来扩容缩容。
四十六、deployment的更新升级策略有哪些？
答：deployment的升级策略主要有两种。
1、Recreate 重建更新：这种更新策略会杀掉所有正在运行的pod，然后再重新创建的pod；
2、rollingUpdate 滚动更新：这种更新策略，deployment会以滚动更新的方式来逐个更新pod，同时通过设置滚动更新的两个参数maxUnavailable、maxSurge来控制更新的过程。
四十七、deployment的滚动更新策略有两个特别主要的参数，解释一下它们是什么意思？
答：deployment的滚动更新策略，rollingUpdate 策略，主要有两个参数，maxUnavailable、maxSurge。
maxUnavailable：最大不可用数，maxUnavailable用于指定deployment在更新的过程中不可用状态的pod的最大数量，maxUnavailable的值可以是
一个整数值，也可以是pod期望副本的百分比，如25%，计算时向下取整。
maxSurge：最大激增数，maxSurge指定deployment在更新的过程中pod的总数量最大能超过pod副本数多少个，maxUnavailable的值可以是一个整数
值，也可以是pod期望副本的百分比，如25%，计算时向上取整。
四十八、deployment更新的命令有哪些？
答：可以通过三种方式来实现更新deployment。
1、直接修改yaml文件的镜像版本，然后kubectl apply -f xxx.yaml来实现更新；
2、使用kubectl edit deployment xxx 实现在线更新；
3、使用kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 命令来更新。
四十九、简述一下deployment的更新过程 （经常问）
deployment是通过控制replicaset来实现，由replicaset真正创建pod副本，每更新一
deployment，都会创建新的replicaset，下面来举例deployment的更新过程：假设要升级一个nginx-deployment的版本镜像为nginx:1.9，deployment的定义滚动更新参数如下：
replicas: 3
deployment.spec.strategy.type: RollingUpdate
maxUnavailable：25%
maxSurge：25%通过计算我们得出，3*25%=0.75，maxUnavailable是向下取整，则maxUnavailable=0，maxSurge是向上取整，则maxSurge=1，所以我们得出在整个deployment升级镜像过程中，不管旧的pod和新的pod是如何创建消亡的，pod总数最大不能超过3+maxSurge=4个，最大pod不可用数3-maxUnavailable=3个。现在具体讲一下deployment的更新升级过程：
使用`kubectl set image deployment/nginx nginx=nginx:1.9 --record` 命令来更新；
1、deployment创建一个新的replaceset，先新增1个新版本pod，此时pod总数为4个，不能再新增了，再新增就超过pod总数4个了；旧=3，新=1，总=4；
2、减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了，再减少就不满足最大pod不可用数3个了；旧=2，新=1，总=3；
3、再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=2，新=2，总=4；
4、减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了；旧=1，新=2，总=3；
5、再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=1，新=3，总=4；
6、减少一个旧版本的pod，此时pod总数为3个，更新完成，pod都是新版本了；旧=0，新=3，总=3；
五十、deployment的回滚使用什么命令
在升级deployment时kubectl set image 命令加上 --record 参数可以记录具体的升级历史信息，使用kubectl rollout history deployment/deployment-nginx 命令来查看指定的deployment升级历史记录，如果需要回滚到某个指定的版本，可以使用kubectl rollout undo deployment/deployment-nginx --to-revision=2 命令来实现。
五十一、讲一下都有哪些存储卷，作用分别是什么?
| 卷 | 作用 | 常用场景 |
|---|---|---|
| emptyDir | 用于存储临时数据的简单空目录 | 一个pod中的多个容器需要共享彼此的数据 ，emptyDir的数据随着容器的消亡也会销毁 |
| hostPath | 用于将目录从工作节点的文件系统挂载到pod中 | 不常用，缺点是，pod的调度不是固定的，也就是当pod消失后deployment重新创建一个pod，而这pod如果不是被调度到之前pod的节点，那么该pod就不能访问之前的数据 |
| configMap | 用于将非敏感的数据保存到键值对中，使用时可以使用作为环境变量、命令行参数arg，存储卷被pods挂载使用 | 将应用程序的不敏感配置文件创建为configmap卷，在pod中挂载configmap卷，可是实现热更新 |
| secret | 主要用于存储和管理一些敏感数据，然后通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息了，pod会自动解密Secret 的信息 | 将应用程序的账号密码等敏感信息通过secret卷的形式挂载到pod中使用 |
| secret | 主要用于存储和管理一些敏感数据，然后通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息了，pod会自动解密Secret 的信息 | 将应用程序的账号密码等敏感信息通过secret卷的形式挂载到pod中使用 |
| projected | 这是一种特殊的卷，用于将上面这些卷一次性的挂载给pod使用 | 将上面这些卷一次性的挂载给pod使用 |
| pvc | pvc是存储卷声明 | 通常会创建pvc表示对存储的申请，然后在pod中使用pvc |
| 网络存储卷 | pod挂载网络存储卷，这样就能将数据持久化到后端的存储里 | 常见的网络存储卷有nfs存储、glusterfs 卷、ceph rbd存储卷 |
五十二、pv的访问模式有哪几种
pv的访问模式有3种，如下：
ReadWriteOnce，简写：RWO 表示，只仅允许单个节点以读写方式挂载；
ReadOnlyMany，简写：ROX 表示，可以被许多节点以只读方式挂载；
ReadWriteMany，简写：RWX 表示，可以被多个节点以读写方式挂载；
五十三、pv的回收策略有哪几种？
主要有2中回收策略：retain 保留、delete 删除。
Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。（这种策略已经被废弃，不用记）
五十四、在pv的生命周期中，一般有几种状态
pv一共有4中状态，分别是：
创建pv后，pv的的状态有以下4种：Available（可用）、Bound（已绑定）、Released（已释放）、Failed（失败）
Available，表示pv已经创建正常，处于可用状态；
Bound，表示pv已经被某个pvc绑定，注意，一个pv一旦被某个pvc绑定，那么该pvc就独占该pv，其他pvc不能再与该pv绑定；
Released，表示pvc被删除了，pv状态就会变成已释放；
Failed，表示pv的自动回收失败；
五十五、怎么使一个node脱离集群调度，比如要停机维护但又不能影响业务应用？
要使一个节点脱离集群调度可以使用kubectl cordon <node-name> 命令使节点不可调度，该命令其实背后原理就是给节点打上node-status.kubernets.io/unschedulable污点，这样新的pod如果没有容忍将不会调度到该节点，但是已经存在于该节点的pod仍然可以继续在该节点上运行不受影响，除非pod消忙了被重新调度了。如果需要恢复节点重新调度，可以使用kubectl uncordon <node-name> 命令恢复节点可调度。
如果节点是要停机维护，则可以对节点上的pod 进行驱逐：使用kubectl drain <node-name>命令用于将节点上的pod驱逐出去，以便对节点进行维护。
kubectl drain 命令的语法如下：
kubectl drain <node-name>
--ignore-daemonsets 参数用于忽略由DaemonSet控制器管理的Pods，不加该参数会报错；
--delete-local-data 参数用于在节点上删除所有本地数据，包括PersistentVolume和PersistentVolumeClaim等资源；
--force 参数强制删除pod，默认删除的是ReplicationController, ReplicaSet, Job, DaemonSet 或者StatefulSet创建的Pod，如果有静态pod，则需要设置强制执行删除的参数--force。
kubectl drain 命令背后原理其实还是首先将指定的节点标记为不可调，从而阻止新 pod 分配到节点上（实质上是 kubectl cordon），然后删除pod。
综上所述，要停机维护：
1、kubectl cordon node01 #设置节点不可调度
2、kubectl drain node01 --ignore-daemonsets --force #驱逐pod
3、kubectl uncordon node01 #恢复节点调度
五十六、pv存储空间不足怎么扩容?
一般的，我们会使用动态分配存储资源，在创建storageclass时指定参数 allowVolumeExpansion：true，表示允许用户通过修改pvc申请的存储空间自动完成pv的扩容，当增大pvc的存储空间时，不会重新创建一个pv，而是扩容其绑定的后端pv。这样就能完成扩容了。但是allowVolumeExpansion这个特性只支持扩容空间不支持减少空间。
五十七、k8s生产中遇到什么特别影响深刻的问题吗，问题排查解决思路是怎么样的？（重点）
（此问题被问到的概率高达90%，所以可以自己准备几个自己在生产环境中遇到的问题进行讲解）
答：前端的lb负载均衡服务器上的keepalived出现过脑裂现象。
1、当时问题现象是这样的，vip同时出现在主服务器和备服务器上，但业务上又没受到影响；
2、这时首先去查看备服务器上的keepalived日志，发现有日志信息显示凌晨的时候备服务器出现了vrrp协议超时，所以才导致了备服务器接管了vip；查看主服务器上的keepalived日志，没有发现明显的报错信息，继续查看主服务器和备服务器上的keepalived进程状态，都是running状态的；查看主服务器上检测脚本所检测的进程，其进程也是正常的，也就是说主服务器根本没有成功执行检测脚本（成功执行检查脚本是会kill掉keepalived进程，脚本里面其实就是配置了检查nginx进程是否存活，如果检查到nginx不存活则kill掉keepalived，这样来实现备服务器接管vip）；
3、排查服务器上的防火墙、selinux，防火墙状态和selinux状态都是关闭着的；
4、使用tcpdump工具在备服务器上进行抓取数据包分析，分析发现，现在确实是备接管的vip，也确实是备服务器也在对外发送vrrp心跳包，所以现在外部流量应该都是流入备服务器上的vip；
5、怀疑：主服务器上设置的vrrp心跳包时间间隔太长，以及检测脚本设置的检测时间设置不合理导致该问题；
6、修改vrrp协议的心跳包时间间隔，由原来的2秒改成1秒就发送一次心跳包；检测脚本的检测时间也修改短一点，同时还修改检测脚本的检测失败的次数，比如连续检测2次失败才认定为检测失败；
7、重启主备上的keepalived，现在keepalived是正常的，主服务器上有vip，备服务器上没有vip；
8、持续观察：第二天又发现keepalived出现过脑裂现象，vip又同时出现在主服务器和备服务器上，又是凌晨的时候备服务器显示vrrp心跳包超时，所以才导致备服务器接管了vip；
9、同样的时间，都是凌晨，vrrp协议超时；很奇怪，很有理由怀疑是网络问题，询问第三方厂家上层路由器是否禁止了vrrp协议，第三方厂家回复，没有禁止vrrp协议；
10、百度、看官方文档求解；
11、百度、看官网文档得知，keepalived有2种传播模式，一种是组播模式，一种是单播模式，keepalived默认在组播模式下工作，主服务器会往主播地址224.0.0.18发送心跳包，当局域网内有多个keepalived实例的时候，如果都用主播模式，会存在冲突干扰的情况，所以官方建议使用单播模式通信，单播模式就是点对点通行，即主向备服务器一对一的发送心跳包；
12、将keepalived模式改为单播模式，继续观察，无再发生脑裂现象。问题得以解决。
答：测试环境二进制搭建etcd集群，etcd集群出现2个leader的现象。
1、问题现象就是：刚搭建的k8s集群，是测试环境的，搭建完成之后发现，使用kubectl get nodes 显示没有资源，kubectl get namespace 一会能正常显示全部的命名空间，一会又显示不了命名空间，这种奇怪情况。
2、当时经验不是很足，第一点想到的是不是因为网络插件calico没装导致的，但是想想，即使没有安装网络插件，最多是node节点状态是notready，也不可能是没有资源发现呀；
3、然后想到etcd数据库，k8s的资源都是存储在etcd数据库中的；
4、查看etcd进程服务的启动状态，发现etcd服务状态是处于running状态，但是日志有大量的报错信息，日志大概报错信息就是集群节点的id不匹配，存在冲突等等报错信息；
5、使用etcdctl命令查看etcd集群的健康状态，发现集群是health状态，但是居然显示有2个leader，这很奇怪（当初安装etcd的时候其实也只是简单看到了集群是健康状态，然后没注意到有2个leader，也没太关注etcd服务进程的日志报错信息，以为etcd集群状态是health状态就可以了）
6、现在etcd出现了2个leader，肯定是存在问题的；
7、全部检测一遍etcd的各个节点的配置文件，确认配置文件里面各个参数配置都没有问题，重启etcd集群，报错信息仍未解决，仍然存在2个leader；
8、尝试把其中一个leader节点踢出集群，然后再重新添加它进入集群，仍然是报错，仍然显示有2个leader；
9、尝试重新生成etcd的证书，重新颁发etcd的证书，问题仍然存在，仍然显示有2个leader；日志仍是报错集群节点的id不匹配，存在冲突；
10、计算etcd命令的MD5值，确保各个节点的etcd命令是相同的，确保在scp传输的时候没有损耗等等，问题仍未解决；
11、无解，请求同事，架构师介入帮忙排查问题，仍未解决；
12、删除全部etcd相关的文件，重新部署etcd集群，etcd集群正常了，现在只有一个leader，使用命令kubectl get nodes 查看节点，也能正常显示了；
13、最终问题的原因也没有定位出来，只能怀疑是环境问题了，由于是刚部署的k8s测试环境，etcd里面没有数据，所以可以删除重新创建etcd集群，如果是线上环境的etcd集群出现这种问题，就不能随便删除etcd集群了，必须要先进行数据备份才能进行其他方法的处理。
五十八、什么是Kubernetes的Service Account，它有什么用途？
Service Account是Kubernetes中用于访问API服务器的身份凭证。每个Service Account都与一个或多个Secret相关联，这些Secret包含用于身份验证的令牌（token）和证书。
Service Account的主要用途是为运行在集群中的Pod提供API访问权限。与常规用户账户不同，Service Account与特定的命名空间相关联，并且只能在该命名空间内访问资源。这使得Service Account成为管理Pod对API服务器访问权限的便捷方式。
五十九、Kubernetes如何管理持久化存储？
通过Persistent Volumes (PV) 和 Persistent Volume Claims (PVC)。PV代表集群中的一块存储资源，而PVC是用户对存储的请求。Kubernetes自动或手动匹配PV和PVC，实现存储资源的动态分配和回收。
六十、Kubernetes如何实现访问控制和权限管理？
使用Role-Based Access Control (RBAC)，通过角色和角色绑定来控制用户或服务账户对资源的操作权限，确保最小权限原则。
Role（角色）：Role 定义了一组操作权限的集合，可以授予指定命名空间内的用户或用户组。Role 只能用于授予命名空间内资源的权限，如 Pod、Service、Deployment 等。
RoleBinding（角色绑定）：RoleBinding 将 Role 与用户或用户组之间进行绑定，指定了哪些用户或用户组具有特定的权限。一个 RoleBinding 可以将多个用户或用户组与一个 Role 相关联。
ClusterRole（集群角色）：ClusterRole 类似于 Role，但作用范围更广泛，可以授予集群范围内资源的权限，如节点、命名空间、PersistentVolume 等。ClusterRole 不限于单个命名空间。
ClusterRoleBinding（集群角色绑定）：ClusterRoleBinding 将 ClusterRole 与用户或用户组之间进行绑定，指定了哪些用户或用户组具有特定的集群级别权限。一个 ClusterRoleBinding 可以将多个用户或用户组与一个 ClusterRole 相关联。
六十一、如何确保Kubernetes集群的安全性？
安全措施包括：使用安全网络策略限制Pod间通信，加密通信（如TLS），使用安全的容器运行时，定期安全扫描，管理好Secrets和ConfigMaps，以及启用网络策略和Pod安全策略等。
六十二、在Kubernetes中，你如何管理持久化存储？
在Kubernetes中，管理持久化存储通常使用PersistentVolumes (PV) 和 PersistentVolumeClaims (PVC)。PV是集群中一块可用的网络存储，而PVC是用户存储需求的声明。PVC和PV之间的关系是通过匹配PVC的需求与PV的属性来实现的。
用户通过创建PVC来请求特定大小和访问模式的存储，而集群管理员则负责创建PV，这些PV可以绑定到PVC上以满足用户的存储需求。此外，还可以使用StorageClass来实现动态的存储供应，即当PVC被创建时，会自动根据StorageClass的定义来创建PV。
六十三、描述Kubernetes的亲和性和反亲和性规则，并解释它们如何影响Pod的调度
Kubernetes的亲和性和反亲和性规则用于影响Pod的调度
亲和性 (Affinity)：指定Pod倾向于被调度到哪些Node上。这可以通过节点亲和性（基于Node的标签）或Pod亲和性（基于其他Pod的标签）来实现。例如，你可能希望将某些Pod调度到具有特定硬件或特定版本操作系统的节点上。
反亲和性 (Anti-Affinity)：指定Pod不应该被调度到哪些Node上。这通常用于确保Pod之间的高可用性。例如，你可以设置反亲和性规则，使得同一服务的Pod不会被调度到同一个节点上，从而防止节点故障导致服务中断。
六十四、Kubernetes中的Ingress是什么，它如何工作？
Ingress是Kubernetes的一个API对象，用于管理外部对集群服务的HTTP和HTTPS访问。它提供了一个外部URL路由到集群内部服务的方式，可以基于域名、路径等规则进行路由。
Ingress控制器负责实现Ingress对象定义的路由规则。当Ingress对象被创建时，Ingress控制器会读取该对象的配置，并根据配置设置路由规则。常见的Ingress控制器有Nginx Ingress Controller、Traefik等。这些控制器会将Ingress规则转换为Nginx、HAProxy或其他负载均衡器的配置，以实现HTTP和HTTPS路由。
六十五、Kubernetes的自动伸缩（Autoscaling）是如何工作的？
Kubernetes支持两种自动伸缩机制：水平伸缩（Horizontal Pod Autoscaling, HPA）和垂直伸缩（Vertical Pod Autoscaling, VPA）。
水平伸缩（HPA）：根据Pod的资源使用情况（如CPU、内存）或自定义指标（如应用特定的性能指标）自动增加或减少Pod的副本数量。HPA控制器会定期查询API服务器以获取Pod的资源使用情况，并根据配置的策略进行伸缩操作。
垂直伸缩（VPA）：根据Pod的资源使用情况自动调整Pod的资源请求（requests）和限制（limits）。VPA控制器会分析Pod的历史资源使用情况，并预测其未来的资源需求，然后更新Pod的YAML配置文件以实现垂直伸缩。
六十七、Kubernetes中的DaemonSet是什么，它通常用于什么场景？
DaemonSet确保在集群中的每个节点上运行一个Pod的副本。当节点加入集群时，DaemonSet会为其调度一个Pod。当节点从集群中移除时，DaemonSet也会清理该节点上的Pod。DaemonSet通常用于运行集群级别的守护进程，例如存储守护进程、日志收集器、网络插件等。
六十八、Kubernetes中的StatefulSet和Deployment有什么区别？
StatefulSet用于管理有状态的应用程序，例如数据库、分布式存储系统等。StatefulSet提供了稳定的网络标识符、稳定的存储和有序的部署、扩展和删除。与Deployment不同，StatefulSet中的Pod不是完全可替换的，每个Pod都有一个唯一的标识。而Deployment主要用于管理无状态的应用程序，它提供了滚动更新、回滚和扩展等功能。
六十九、Kubernetes中的ConfigMap和Secret如何用于应用程序配置？
ConfigMap和Secret都是Kubernetes中用于存储应用程序配置信息的资源对象。ConfigMap用于存储非敏感的配置信息，如配置文件、环境变量等。Secret则用于存储敏感的配置信息，如密码、密钥等。这些信息可以被挂载到Pod中的容器文件系统中，或者以环境变量的形式注入到容器中，供应用程序使用。
七十、Kubernetes中的准入控制器（Admission Controllers）是什么，它们如何影响集群的行为？
准入控制器是Kubernetes API服务器中的一段代码，用于拦截发送到API服务器的请求，在它们持久化到存储之前进行更改或拒绝。这些控制器允许集群管理员定义并强制执行自定义的策略，以确保请求满足集群的安全性和业务规则。例如，准入控制器可以用于限制对资源的访问、验证Pod的安全配置或实施配额。
七十一、Kubernetes中的CNI是什么，它在集群中的作用是什么？
CNI（容器网络接口）是一个规范，用于定义容器如何连接到网络。在Kubernetes集群中，CNI允许使用各种网络插件来实现Pod之间的网络通信。这些插件负责设置网络接口、分配IP地址、配置路由等。通过使用CNI，Kubernetes可以支持多种网络解决方案，包括Flannel、Calico等。
七十二、Kubernetes中的Ingress是什么？它如何与Service一起工作？
Ingress是Kubernetes的一个API对象，用于管理集群外部对集群内部服务的HTTP和HTTPS路由。Ingress提供了一种集中定义路由规则的方式，使得来自集群外部的请求能够被正确地转发到集群内部的服务上。Ingress需要配合Ingress Controller一起使用，Ingress Controller是一个负责监听Ingress对象并据其配置转发规则的组件。Service是Kubernetes中的另一个API对象，用于为Pod提供稳定的网络访问地址。Ingress通常会将请求转发到某个Service上，再由Service将请求分发到具体的Pod上。
七十三、Kubernetes中的服务发现是如何工作的？
Kubernetes通过DNS和Service资源对象来实现服务发现。当Pod启动时，它会向集群的DNS服务器注册自己的IP地址和主机名。然后，其他Pod可以通过服务名来访问该Pod，DNS服务器会将服务名解析为对应的Pod IP地址。此外，Kubernetes还提供了Service对象来抽象Pod的集合，并为它们提供负载均衡和发现功能。管理员可以创建Service对象来定义服务的名称、端口和选择器等属性，并将它们与Pod关联起来。其他Pod可以通过Service的名称和端口来访问该服务。