网站内容建设包括什么,龙岩设计师,wordpress获取手机号,东莞住房和城乡建设厅官网目录
三十六、pod的定义中有个command和args参数#xff0c;这两个参数不会和docker镜像的entrypointc冲突吗#xff1f;
三十七、标签及标签选择器是什么#xff0c;如何使用#xff1f;
三十八、service是如何与pod关联的#xff1f;
三十九、service的域名解析格式…
目录
三十六、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.clusterdomainservicename是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创建的podstatefulset.spec.serviceName字段解释如下
[rootmatser ~]# 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 wherepod-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:6379pod里面的后端应用程序就可以拿这串字符串去连接Redis集群了。
四十、service的类型有哪几种
service的类型一般有4种分别是
ClusterIP表示service仅供集群内部使用,默认值就是ClusterIP类型NodePort表示service可以对外访问应用,会在每个节点上暴露一个端口,这样外部浏览器访问地址为任意节点的IPNodePort就能连上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的svccurl http://${KUBERNETES_SERVICE_HOST}:{KUBERNETES_SERVICE_PORT}2、DNS方式使用dns域名解析的前提是k8s集群内有DNS域名解析服务器默认k8s中会有一个CoreDNS作为k8s集群的默认DNS服务器提供域名解析服务器service的DNS域名表示格式为servicename.namespace.svc.clusterdomainservicename是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同名的endpointendpoint中定义外部服务的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就可以在集群中随时被创建或销毁。endpointservice维护一个叫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-proxykube-proxy运行在node节点上在Node节点上实现Pod网络代理维护网络规则和四层负载均衡工作kube-proxy会监听api-server中从而获取service和endpoint的变化情况创建并维护路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
四十四、无头service和普通的service有什么区别无头service使用场景是什么 答无头service没有cluster ip在定义service时将 service.spec.clusterIPNone就表示创建的是无头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 --replicas5 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 busyboxbusybox nginxnginx:1.9.1 命令来更新。
四十九、简述一下deployment的更新过程 经常问
deployment是通过控制replicaset来实现由replicaset真正创建pod副本每更新一
deployment都会创建新的replicaset下面来举例deployment的更新过程假设要升级一个nginx-deployment的版本镜像为nginx:1.9deployment的定义滚动更新参数如下
replicas: 3
deployment.spec.strategy.type: RollingUpdate
maxUnavailable25%
maxSurge25%通过计算我们得出3*25%0.75maxUnavailable是向下取整则maxUnavailable0maxSurge是向上取整则maxSurge1所以我们得出在整个deployment升级镜像过程中不管旧的pod和新的pod是如何创建消亡的pod总数最大不能超过3maxSurge4个最大pod不可用数3-maxUnavailable3个。现在具体讲一下deployment的更新升级过程
使用kubectl set image deployment/nginx nginxnginx: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-revision2 命令来实现。
五十一、讲一下都有哪些存储卷作用分别是什么?
卷作用常用场景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使用pvcpvc是存储卷声明通常会创建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 EBSGCE PDAzure DiskOpenStack 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时指定参数 allowVolumeExpansiontrue表示允许用户通过修改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地址、配置路由等。通过使用CNIKubernetes可以支持多种网络解决方案包括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可以通过服务名来访问该PodDNS服务器会将服务名解析为对应的Pod IP地址。此外Kubernetes还提供了Service对象来抽象Pod的集合并为它们提供负载均衡和发现功能。管理员可以创建Service对象来定义服务的名称、端口和选择器等属性并将它们与Pod关联起来。其他Pod可以通过Service的名称和端口来访问该服务。
