K8s常见问题记录
Kubernetes 是一个开源的容器编排平台,用于管理容器化的工作负载和服务,方便进行声明式配置和自动化。(yaml 即声明式)为容器化的应用提供。
目录
Q2:简述 Kubernetes 集群相关组件?各自的作用是什么
Q6:简述 Kubernetes PV 和 PVC?/如何管理持久化存储?
Q9:描述Kubernetes的亲和性和反亲和性规则,并解释它们如何影响Pod的调度
Q10. Kubernetes中的Ingress是什么,它如何工作的?
Q11:描述Kubernetes中Pod的生命周期以及常见的生命周期钩子?
Q12:Kubernetes的自动伸缩(Autoscaling)是如何工作的?
Q13:什么是Kubernetes的Service Account,它有什么用途
Q14:描述Kubernetes的滚动更新(Rolling Update)和重新创建(Recreate)策略?
Q15:Kubernetes中的DaemonSet是什么,它通常用于什么场景?
Q16: k8s中有状态和无状态是什么,两者有什么区别?/ Kubernetes中的DaemonSet是什么,它通常用于什么场景?
Q17:Kubernetes中的Sidecar容器是什么,它有什么用途?
Q18:Kubernetes中的准入控制器(Admission Controllers)是什么,它们如何影响集群的行为?
Q19:Kubernetes中的Taint和Toleration是什么,它们如何影响Pod的调度?
Q20:在Kubernetes中,QoS类别是如何定义的?请解释Guaranteed、Burstable和BestEffort的区别
Q21:Kubernetes中的PodSecurityPolicy是什么?它如何帮助增强集群的安全性?
Q22:Kubernetes中的PodDisruptionBudget是什么?它如何帮助确保应用程序的高可用性?
Q23:简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet?
Q25:简述 Kubernetes 创建一个 Pod 的主要流程?
Q26:简述 Kubernetes 中 Pod 的健康检查方式?
Q27:简述 Kubernetes 中 Pod 的重启策略?
Q34:简述 Kubernetes 如何进行优雅的节点关机维护?
Q35:简述 Kubernetes 中,如何使用 EFK 实现日志的统一管理?
Q1:简述什么是 Kubernetes?
Kubernetes 是一个开源的容器编排平台,用于管理容器化的工作负载和服务,方便进行声明式配置和自动化。(yaml 即声明式)
为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力,多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力
Q2:简述 Kubernetes 集群相关组件?各自的作用是什么
1.控制平面组件(Control Plane Components)
kube-apiserver:提供集群的前端接口、处理REST请求、存储数据到ETCD、与其它组件通信
etcd:分布式键值存储,存储集群的配置数据和状态
controller-manager:管理控制器,如replication controller(管理 Pod 的副本,确保与期望值一致)、deployment controller,确保实际状态与预期状态一致
kube-scheduler:根据资源的情况,将pod调度到合适的节点上
2.Node组件(worker node)
kubelet:在每个节点运行,负责pod的创建、启停等生命周期的管理kube-proxy:实现服务的网络代理功能,如负载均衡,确保pod之间的通讯(运行在每个节点上的
kube-proxy
负责监听 Service 和 Endpoints 的变化,并维护相应的 iptables 规则或 IPVS 规则,确保流量能够正确路由到相应的 Pod。默认用轮询的方式做集群内部的负载均衡)container runtime:如docker或containerd,在节点上执行容器
标记一个 Node 为不可调度:kubectl cordon $NODENAME
kube-proxy ipvs 和 iptables 的区别:
iptables 与 IPVS 都是基于 Netfilter 实现的;但
iptables 是为防火墙而设计的;IPVS 则专门用于高性能负载均衡,并使用更高效的数据结构(Hash 表),允许几乎无限的规模扩张。
Q3:k8s的基础概念?
Master/control-plane:k8s的管理节点,负责管理集群,提供集群数据资源的访问入口,运行apiserver、controller manager等进组件
Node/worker node:运行pod的服务节点,运行docker runtime、kubelet、kube-proxy
Pod:Pod运行在node/worker node,Pod是kubernets创建、调度和管理的最小单元;一个pod可以包含一个或多个容器
Deployment:为Pod和ReplicaSet(运行指定数量的 Pod 副本)提供声明式的更新能力(或者,是一种声明式地管理应用程序副本(Replica)的资源对象)
Replication Controller/RC:用来管理pod的副本,保证pod数量与预期一致;是实现弹性伸缩、动态扩容和滚动升级的核心
PV:(Persistent Volume)持久卷是一种用于管理存储资源的抽象对象。独立于 Pod 的生命周期,用来做持久化数据存储
Service:用来管理和暴露应用程序的网络访问的资源,类型有:ClusterIP(默认的类型,该IP仅在集群内部使用)、Nodeport(集群外部可访问)、LoadBalancer(常用于公有云的负载均衡)、externalName(将service 映射到外部的DNS名称)
ConfigMap:是一种API对象,将非机密数据保持到键值对中,可用作环境变量或挂载上去给pod 用(存储卷中的配置文件
HPA(Horizontal Pod Autoscaler):pod的横向自动扩容,根据追踪分析RC控制的pod的负载情况,来动态调整pod的副本数量
Namespace:将集群的资源在逻辑上分隔开的一种方法,类似文件夹把不同的资源分类、隔离管理
Q4:Service如何实现服务发现和负载均衡?
服务发现:
1.DNS解析:kubernets的DNS服务会为每个service创建一条DNS记录,集群中的pod都可以通过DNS名称访问service(例子:集群中的"default" namespace中有个my-service的service,pod可以通过my-service.default.svc.cluster.local这个名称访问它)
2.环境变量:在每个pod启动时,kubernets会为集群中的所有service的IP和端口创建环境变量,应用程序通过环境变量直接访问service
负载均衡:
1.ClusterIP:默认的service类型,提供访问集群的IP地址,自动将流量分发到与service相关联的pod上
2.Nodeport:适用集群外部访问,为集群节点分配一个端口(30000-32767),将外部流量路由到该端口,再负载均衡到相关联的pod
3.LoadBalancer:云提供商的负载均衡器,这个类型的service会自动创建外部负载均衡器,将外部的流量负载均衡至相关联的pod4.externalName:适用需要外部服务的场景,将内部的请求转发到外部的DNS
Q5:Kubernetes网络模型的核心原则是什么?
核心原则是每个pod一个IP,确保pod之间通信像同一局域网内一样简单,且不依赖于pod所在的节点,网络插件(flannel、calico实现此模型)
flannel和calico的区别:(重点会问)
calico补充:
特性 Flannel Calico 原理 使用Overlay网络,在底层物理网络之上
创建虚拟的网络层基于L3即网络层路由,直接在底层网络
上路由性能 较低 (由于 overlay 网络开销) 较高 (直接 L3 路由) 安装和配置 简单易用 相对复杂 网络策略支持 基本支持 高级支持 (细粒度访问控制) 适用场景 小规模集群,测试环境 大规模生产环境,要求高性能和安全性 依赖 etcd,flanneld BGP,Felix
BGP是一种网络架构,主要依赖于第 3 层(网络层)的路由协议,尤其是 BGP(边界网关协议,Border Gateway Protocol),用于管理网络中不同子网之间的路由
支持的高级网络策略有:
1.细粒度的流量控制:允许自定义哪些pod之间可以互相通信;自定义允许哪些pod可访问特定的服务
2.ingress和egress流量控制:控制ingress入站流量和egress出站流量
3.DNS策略:允许你控制pod可解析哪些DNS
4.支持多集群环境等等
Kubernetes中的CNI(容器网络接口)是什么,它在集群中的作用是什么?
CNI是一种规范,用于定义容器如何连接网络;
作用是:pod之间的网络通信,设置网络接口、分配IP地址、配置路由;常用的插件是flannel和calico
Q6:简述 Kubernetes PV 和 PVC?/如何管理持久化存储?
管理持久化存储通常使用PersistentVolumes (PV) 和 PersistentVolumeClaims (PVC)。
PV(persistent volume):持久卷是一种用于管理存储资源的抽象对象。独立于 Pod 的生命周期,用来做持久化数据存储;可以创建pv的插件有:NFS、iSCSI、CephFS、RBD等等
PVC(persistent volume claim):用户对存储资源的请求(包括大小和访问模式);在pvc中可自定义特定的大小和访问模式(ReadWriteOnce、ReadOnlyMany、ReadWriteMany(卷可以被多个节点以读写方式挂载。)、ReadWriteOncePod)
创建PV分为静态创建和动态创建:
静态创建:管理员手动创建若干 PV 卷,用于持久化数据存储(例子:如果是用nfs创建pv给pod使用,先创建pv要指定nfs server等信息,然后创建pvc(会根据请求的情况自动bound PV),然后创建pod指定使用该pvc)
动态创建:是基于 StorageClass 来实现的,首选创建storagclass是需要指定csi(一般由存储厂商提供,provisioner字段),然后创建pvc时再指定使用该storageclass
pv的状态:Available即可用的;Bound 即已经使用,或绑定了;Failed 自动回收了,卷操作失败;Released 被删除了
pv的回收策略有:即设置persistentVolumeReclaimPolicy字段
1.Retain(保留):当 PV 绑定的 PVC 被删除时,PV 将被保留,数据仍然存在,需手动管理
2.Delete:当 PV 绑定的 PVC 被删除时,PV 也会被删除,并且其数据也会被永久删除
3.Recycle:清空数据后重新使用,即 rm -rf /thevolume/*(只有 NFS 和 HostPath 支持)
其它关于pv和pvc的问题:
1.容器如何使用多个pv/挂在卷?
容器可以使用多个pv/挂在卷,不同pv可用作不同的用途
2.一个pv/挂在卷能否给同一pod里面的多个容器使用?
可以,常用于多个容器之间共享数据或配置(类型:emptyDir、hostpath)
3.一个pv/挂在卷能给多个pod使用吗?
可以但是取决于存储插件是否支持readwriteMany(RWM,PV 可以被多个节点上的多个 Pod 以读写方式挂载),支持的有:NFS、GlusterFS
storage class yaml文件:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor
provisioner: linstor.csi.linbit.com
parameters:
autoPlace: "2"
storagePool: "pool1"
pvc yaml文件:
root@k8smaster:~# cat linstor_pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
spec:
storageClassName: linstor
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Q7:Kubernetes 数据持久化的方式有哪些?
emptyDir:一般是作为临时存储使用,数据持久化的生命周期和使用的 pod 一致
Hostpath:将宿主机上已存在的目录或文件挂载到容器内部。
PersistentVolume(简称 PV):如基于 NFS 服务的 PV,作用是统一数据持久化目录,方便管理
Q8:Kubernetes如何实现访问控制和权限管理?
使用Role-Based Access Control (RBAC),通过角色和角色绑定来控制用户或服务账户对资源的操作权限,确保最小权限原则。
比如:
1.Role:可以指定命名空间的用户或用户组仅具备deployment、pod、service的操作权限(get,list,watch,create等操作)
2.RoleBinding:RoleBinding将Role和用户或用户组绑定在一起,指定了哪些用户或用户组具备哪些权限
3.ClusterRole:类似Role,但范围更广,可以授予集群范围资源的权限,如节点、命名空间、PersistentVolume、Statefulset、daemonSet
4.ClusterRoleBinding:ClusterRoleBinding 将 ClusterRole 与用户或用户组之间进行绑定
Q9:描述Kubernetes的亲和性和反亲和性规则,并解释它们如何影响Pod的调度
亲和性:指定pod倾向被调度于哪个节点上。常见的做法是 label + node Affinity,或者 label + pod affinity
反亲和性:指定pod不应被调度到哪个节点。常用于确保pod的高可用场景
也可以通过label + node selector来实现,但affinity更灵活
Q10. Kubernetes中的Ingress是什么,它如何工作的?
Ingress是一种Kubernetes资源,用于将外部流量路由集群内的服务,可以提供负载均衡、SSL终止、可基于主机名和路径来路由(需要配合Ingress Controller一起使用)
- 负载均衡:根据负载均衡策略将外部流量分发到后端服务上。
- 路径路由:根据URL路径,将流量路由到不同的后端服务。
- 域名路由:根据请求的域名,将流量路由到不同的后端服务。
- SSL终止:可以在Ingress层终止SSL/TLS,从而简化后端服务的配置。
- 身份验证和授权:可以与外部身份验证和授权系统集成。
Ingress如何工作:
当ingress对象被创建时,ingress控制器会读取ingress对象的配置,然后根据配置设置路由规则(比如说:将Ingress规则转换成Nginx、HAproxy负载均衡器的配置,以实现HTTP/HTTPS路由)
Ingress如何与Service一起工作?
Ingress通常会将请求转发到某个Service上(Service是Kubernetes中的另一个API对象,用于为Pod提供稳定的网络访问地址),再由Service将请求分发到具体的Pod上。
Q11:描述Kubernetes中Pod的生命周期以及常见的生命周期钩子?
pod的生命周期:创建开始,经历运行、重启、终止等状态,最终可能被删除。
生命周期钩子允许你在容器启动和终止时执行特定的代码,对处理初始化和清理任务时非常有用
常见的生命周期钩子包括:
PostStart:在容器创建后立即执行一次。常用于初始化容器环境或启动后台进程
PreStop:在容器终止之前执行。常用于优雅地关闭容器中的服务或清理资源。
Q12:Kubernetes的自动伸缩(Autoscaling)是如何工作的?
水平伸缩(Horizontal Pod Autoscaling,HPA):根据pod的CPU、内存资源使用情况来自动增加或减少pod的副本数量。HPA会定期从apiserver中查询pod资源使用的情况,并根据配置的策略进行伸缩操作
垂直伸缩(Vertical Pod Autoscaling,VPA):根据pod的资源使用情况自动调整pod的request和limit。VPA控制器会分析pod的历史资源使用情况,并预测未来的资源需求,然后更新pod的yaml配置文件实现垂直伸缩
Q13:什么是Kubernetes的Service Account,它有什么用途
Service account/ServiceAcount 是pod内部进程访问API服务器的身份凭证,每个service account与一个或多个secret相关联
secret包含身份验证的令牌和证书
/etc/kubernetes/pki 存放验证的秘钥,例如:apiserver.crt、ca.crt、sa.pub等
Kubernetes中的ConfigMap和Secret如何用于应用程序配置?
ConfigMap和Secret都是用于存储应用程序的配置信息;
ConfigMap常用于存储非敏感数据,例如:配置文件、环境变量
Secret常用于存储秘钥、密码等敏感数据;
这些信息都可被挂载到pod中容器的文件系统中;或者以环境变量的方式注入到容器中
Kubernetes中的Service Account是什么?它与User Account有何不同?
ServiceAccount主要用于:pod内部进程与kubernets API服务器进行交互(生命周期:pod删除,service account也会被删除)
User account主要用于外部用户或客户端与kubernets API服务器进行交互
Service Account 的用途
主要是访问控制的功能,限制访问的k8s资源(deployment、pod)和可执行的操作(get、list)
- 身份标识:为运行在 Pod 内的应用程序提供身份标识。
- 访问控制:通过与 Role-Based Access Control (RBAC) 集成,控制 Role 能够访问哪些 Kubernetes API 资源(API资源:pod、deployment、service、pv、daemonset、ingress等)
- API 访问:Pod 内的应用程序可以使用 Service Account 来访问 Kubernetes API 进行各种操作,如查看和管理资源。
Q14:描述Kubernetes的滚动更新(Rolling Update)和重新创建(Recreate)策略?
重新创建:会停止并删除所有旧的Pod实例,然后再创建新的Pod实例,服务会中断
滚动更新:即在不中断服务的情况下逐步替换旧版本的Pod,滚动更新可以通过Kubernetes的Deployment对象来实现
操作:1.配置yaml文件时,策略strategy配置为rollingUpdate; 2.更换image来实现滚动更新的话(1.19.8假设是新版),命令是:kubectl set image deployment/nginx-deployment nginx=nginx:1.19.8 --record
Q15:Kubernetes中的DaemonSet是什么,它通常用于什么场景?
DaemonSet确保集群内的每个节点都运行一个pod副本(节点加入,为该节点调度一个pod;节点删除,清理该节点的pod);常用于集群级别的守护进程,例如:网络插件、日志收集器、存储守护进程
Q16: k8s中有状态和无状态是什么,两者有什么区别?/ Kubernetes中的statefulset是什么,它通常用于什么场景?
无状态应用是不保存客户端会话数据或状态的应用程序;
有状态应用是保存客户端会话数据和状态的应用程序,并且通常依赖于持久化存储
管理方式 | 数据持久化 | 拓展和缩减 | 应用场景 | |
无状态应用 | 一般用deployment来管理 | 无需数据持久化,每个实例都是没区别的 (即可以随意替换) | 容易拓展或缩减实例; | 适用于WEB服务或API服务 |
有状态应用 | 一般用statefulSet来管理 | 需要持久化,每个实例都有独特的状态 (即实例有唯一的身份,不可随意替换 | 拓展或缩减实例需要额外的配置或步骤 (kubectl scale statefulset mysql --replicas=5) | 数据库、分布式存储系统 |
Q17:Kubernetes中的Sidecar容器是什么,它有什么用途?
Sidecar容器是与主应用程序容器一起运行的辅助容器,他们共享相同的pod和命名空间。
用途:给主应用程序容器提供额外的功能或服务,例如:日志收集、监控代理、服务发现
Q18:Kubernetes中的准入控制器(Admission Controllers)是什么,它们如何影响集群的行为?
准入控制器是kubernets api服务器中的一段代码,用于拦截发送到API 服务器的请求,在它们持久化到存储之前拒绝或更改。可自定义策略,以满足集群的安全性和业务规则,例如:可用于限制对资源的访问、验证pod的安全配置(集群范围的策略、验证、资源限制等)
Q19:Kubernetes中的Taint和Toleration是什么,它们如何影响Pod的调度?
Taint(污点) :是附加到节点的键值对,用于表示节点上的某些属性或条件,会限制pod在该节点上运行
Toleration(容忍):是pod规格中的字段,表示Pod可以容忍哪些taint。
当调度器尝试将pod调度到节点时,它会检查节点的taint和pod的toleration,以确保pod可以容忍节点上的所有taint。应用场景:精细控制pod的调度,将pod限制在特定的硬件节点上
Q20:在Kubernetes中,QoS类别是如何定义的?请解释Guaranteed、Burstable和BestEffort的区别
Qos(Quality of Service Class)服务质量,是根据Pod的request(资源请求)和limit(限制)来定义的。
Guaranteed:Pod中每个容器都对CPU和内存进行了限制;Qos最高,优先调度,最后终止
Burstable:Pod中的容器至少一个设置了资源请求,但没做限制。Qos中等,资源紧张时,正常调度,根据情况终止
Besteffort:Pod没有设置资源请求和限制。Qos最低,优先被终止
Q21:Kubernetes中的PodSecurityPolicy是什么?它如何帮助增强集群的安全性?
PodSecurityPolicy(PSP)是K8s集群级别的资源,用于控制pod创建的安全上下文。通过PSP可以定义一系列Pod的安全策略,例如:Pod的特权模式、限制Pod的文件系统访问权限、限制Pod的运行用户。
k8s 原来是设置PodSecurityPolicy privileged=true,有pod已经在跑了,
现在更新PodSecurityPolicy 不允许特权模式,原来设置privileged=true的pod会被停止吗?
不会,但是如果节点重启,新创建的Pod会调度失败,因不符合新的安全策略。
设置PodSecurityPolicy的步骤:
1.自定义和创建PodSecurityPolicy 资源
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: test-psp
spec:
privileged: false # 禁止特权模式
....
....
kubectl apply -f test-psp.yaml
2.创建Role并bind绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: use-test-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- test-psp
verbs:
- use
授予使用 PSP 的权限
resourceNames:
- test-psp
kubectl apply -f test-psp-role.yaml
这里是name: system:serviceaccounts # 为所有服务账户;为所有 serviceaccounts做限制
当然也可指定账户:(如下)
subjects:
- kind: ServiceAccount
name: privileged-sa # 服务账户名称
namespace: default # 服务账户所在的命名空间
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: use-restricted-psp-binding
subjects:
- kind: Group
name: system:serviceaccounts # 为所有服务账户
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: use-test-psp
apiGroup: rbac.authorization.k8s.io
kubectl apply -f use-test-psp-binding.yaml
3.确保 API 服务器启用 PSP
确保 Kubernetes API 服务器启用了 PodSecurityPolicy。检查 API 服务器启动参数,确保包含 --enable-admission-plugins=PodSecurityPolicy
:
kube-apiserver --enable-admission-plugins=PodSecurityPolicy,...
4.验证配置
创建一个测试 Pod,验证其是否符合 PodSecurityPolicy。以下是一个不符合上述 PSP 的 Pod 示例:
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test-container
image: nginx
securityContext:
privileged: true # 这个设置会被拒绝
如果 PSP 正常工作,您应该会看到错误信息,表明 Pod 创建被拒绝,因为它不符合 PSP 要求
用指定account创建pod时的yaml文件(应用场景:如果是PodsecurityPolicy+role+rolebinding,限制了某个账户,可以用其它账号来创建特权模式的pod)
apiVersion: v1
kind: Pod
metadata:
name: privileged-pod
spec:
serviceAccountName: privileged-sa # 使用允许特权 PSP 的服务账户
containers:
- name: privileged-container
image: nginx
securityContext:
privileged: true # 特权模式
Q22:Kubernetes中的PodDisruptionBudget是什么?它如何帮助确保应用程序的高可用性?
PodDisruptionbudget(PDB)是一种机制,用于确保在计划内/计划外的pod中断时,应用程序仍然保持高可用性。
PDB 通过以下两个参数之一来定义:
1.Minavailable:最少要保持可用的pod数量
2.Maxunavailable:最多不可用的pod数量
常用场景:滚动升级、节点升级、pod重新调度
Q23:简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet?
minikube:本地部署单节点k8s的工具
kubectl:是一个命令行工具,用于控制k8s集群管理器,可用于查看集群资源,执行创建、删除等操作
kubectl 是一个命令行工具,用于控制k8s集群管理器,可用于查看集群资源,执行创建、删除等操作(使用 Kubernetes API 与 Kubernetes 集群的控制面板进行通信的命令行工具)
创建deployment命令是:kubectl apply -f deployment_name.yamlkubectl
命令行工具支持多种不同的方式来创建和管理 Kubernetes对象
1.指令式命令:kubectl create deployment nginx --image nginx2.声明式文件:kubectl create -f nginx.yaml
3..声明式目录:kubectl apply -f configs/
kubelet:在每个节点上运行,负责pod的创建、启停等生命周期的管理
Q24:简述 Kubernetes 常见的部署方式?
1.kubeadm部署(推荐)
2.二进制包编译安装
3.minikube:单节点的
Q25:简述 Kubernetes 创建一个 Pod 的主要流程?
a.用户通过命令行工具(kubernets API)提交pod创建的请求
b.API server接收并验证请求,如果请求有效,API Server将pod对象存储到etcd
c.调度器监视未分配的pod,然后根据预定义的策略(affinity/taint等)和资源选择一个合适的节点来运行pod
d.调度器分配节点后,kubelet检测到新的pod分配任务,在指定节点上创建并启动容器
e.容器运行时,从dockerhub或者自定义配置的仓库中拉取image并运行容器
f.kubelet将pod的运行状态更新给apiserver,apiserver将状态存储至etcd
g.所有容器运行成功且满足就绪探针(readiness probe)检查时,pod被标记为就绪状态,可以接受请求
Note:controller manager一直监控集群的状态,确保实际状态与预期状态一致
Q26:简述 Kubernetes 中 Pod 的健康检查方式?
liveness probe探针:用于判断容器是否存活(running状态),如果检测到容器不健康,kubelet kill掉容器,根据重启策略做下一步处理
readiness probe探针:用于判断容器是否启动完成(ready状态),检测到容器失败,则修改容器的状态
Q27:简述 Kubernetes 中 Pod 的重启策略?
restartpolicy的重启策略有:always(默认值)、onfailure、never
1.always:当容器失效时,kubelet自动重启该容器
2.onfailure:当容器终止运行且退出码不为0时,由kubelet自动重启该容器
3.never:不管容器的状态如何,kubelet都不重启该容器
Q28:ETCD的备份与恢复命令?
使用ETCD_API=3 etcdctl ..... snapshot save.....、 ETCD_API=3 etcdctl ..... restore命令执行备份和恢复命令
ETCDCTL_API=3 etcdctl --endpoints=<https://127.0.0.1:2379> --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> snapshot save /srv/data/etcdss.db
ETCDCTL_API=3 etcdctl --endpoints <https://127.0.0.1:2379> --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> snapshot restore /var/xxxx.db
ETCD是一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现
特点:
简单:支持 REST 风格的 HTTP+JSON API
安全:支持 HTTPS 方式的访问
快速:支持并发 1k/s 的写操作
可靠:支持分布式结构,基于Raft的一致性算法(Raft是一套通过选举主节点来实现分布式系统一致性的算法)
该数据库,分布式锁服务有两种方式:1.保持独占 2.控制时序
Q29:Kubernetes 中 Pod 可能位于的状态?
Running:运行状态
pending:正在启动或者正在重启
Succeeded:Pod内容器成功执行退出,不会重启
Failed:容器已退出,但有容器退出为失败状态
Unknown:无法获取容器状态
Q30:Kubernetes 镜像的下载策略
always:总是从指定仓库中获取镜像
never:只能使用本地镜像
ifNotPresent:本地优先(本地没有镜像时,才从仓库中下载)
Q31:获取yaml文件的方式?
1.参考官方文档纯手动编写yaml
2.通过kubectl命令获取yaml,例如:要修改已经在使用的Deployment或者其他资源时,可以使用 kubectl get deployment deployment_name -o yaml > xxx.yaml 来获取 yaml 文件,修改之后使用 kubectl apply xxx.yaml 来进行配置
其它例子:kubectl get service servicet_name -o yaml > xxx_svc.yaml
Q32:简述 Kubernetes 如何保证集群的安全性?
k8s从以系列不同的维度来保证集群的安全
基础设施方面:容器与宿主机的隔离
权限方面:
最小组件原则:合理限制组件的权限,确保组件只执行授权的行为
用户权限:划分普通用户和管理员用户
集群方面:
apiserver认证授权:k8s集群中所有资源的访问和变更都是通过apiserver实现的,所以需要更安全的https和token来识别和认证客户端的身份
通过RBAC方式来提升集群安全授权
AdmissionControl(准入机制):对k8s请求过程中,顺序为:先经过认证和授权,然后走执行准入操作,最后对目标对象进行操作
Q33:k8s升级的步骤?
小结为一句话:首先让节点不可调度和清空节点,去该节点上安装软件并执行upgrade动作,检查是否upgrade成功,最后让节点可调度
1.首先让node不可调度和清空节点
kubectl cordon masternode_name
kubectl drain masternode_name --ignore-daemonsets
2.ssh到节点上,安装软件执行
apt-get install -y kubeadm=1.19.0 kubectl=1.19.0 kubelet=1.19.0
3.执行升级
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.19.0 --etcd-upgrade=false
4.检查升级情况
systemctl status kubelet
kubectl get node (有version信息)
5.让node可调度
kubectl uncordon masternode_name
Q34:简述 Kubernetes 如何进行优雅的节点关机维护?
使用kubectl drain node命令,将pod进行驱逐,然后再进行关机维护
Q35:简述 Kubernetes 中,如何使用 EFK 实现日志的统一管理?
通常应用或服务的组件太多,建议使用EFK系统进行统一管理
EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合,功能如下:
Elasticsearch:是一个搜索引擎,负责提供查询接口和存储日志
Fluentd:fluentd 监控并收集日志,将处理过的日志发送给Elasticsearch
Kibana:提供一个web GUI,用户可以浏览和所有日志
K8s yaml配置文件解释
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # 告知 Deployment 运行 2 个与该模板匹配的 Pod
必须提供对象的 spec(即spec字段)
,用来描述该对象的期望状态, 以及关于对象的一些基本信息(例如:名称,你想要创建的副本数、标签label等)
yaml文件必须的字段和解释:
apiVersion
- 创建该对象所使用的 Kubernetes API 的版本kind
- 想要创建的对象的类别metadata
- 帮助唯一标识对象的一些数据,包括一个name
字符串、UID
和可选的namespace
spec
- 你所期望的该对象的状态(spec格式都是不同的,可自由发挥,包含了特定于该对象的嵌套字段)
strategy:
recreate:删除全部旧的,再创建新版本的pod(应用中断)
RollingUpdate:平滑更新, 逐步替换旧版本
蓝绿(blue/green):新版和旧版本一起发布,然后切换流量
金丝雀(canary):将新版本面向一部分用户发布,然后继续全量发布
A/B测(a/b testing):以精确地方式(HTTP头、cookie等)向部分用户发布新版本
较为详细版解释:
apiVersion: apps/v1 # 指定api版本,此值必须在kubectl api-versions中
kind: Deployment # 指定创建资源的角色/类型
metadata: # 资源的元数据/属性
name: demo # 资源的名字,在同一个namespace中必须唯一
namespace: default # 部署在哪个namespace中
labels: # 设定资源的标签
app: demo
version: stable
spec: # 资源规范字段
replicas: 1 # 声明副本数目
revisionHistoryLimit: 3 # 保留历史版本
selector: # 选择器
matchLabels: # 匹配标签
app: demo
version: stable
strategy: # 策略
rollingUpdate: # 滚动更新
maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
maxUnavailable: 30% # 示在更新过程中能够进入不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
type: RollingUpdate # 滚动更新策略
template: # 模版
metadata: # 资源的元数据/属性
annotations: # 自定义注解列表
sidecar.istio.io/inject: "false" # 自定义注解名字
labels: # 设定资源的标签
app: demo
version: stable
spec: # 资源规范字段
containers:
- name: demo # 容器的名字
image: demo:v1 # 容器使用的镜像地址
imagePullPolicy: IfNotPresent # 每次Pod启动拉取镜像策略,三个选择 Always、Never、IfNotPresent
# Always,每次都检查;Never,每次都不检查(不管本地是否有);IfNotPresent,如果本地有就不检查,如果没有就拉取
resources: # 资源管理
limits: # 最大使用
cpu: 300m # CPU,1核心 = 1000m
memory: 500Mi # 内存,1G = 1000Mi
requests: # 容器运行时,最低资源需求,也就是说最少需要多少资源容器才能正常运行
cpu: 100m
memory: 100Mi
livenessProbe: # pod 内部健康检查的设置
httpGet: # 通过httpget检查健康,返回200-399之间,则认为容器正常
path: /healthCheck # URI地址
port: 8080 # 端口
scheme: HTTP # 协议
# host: 127.0.0.1 # 主机地址
initialDelaySeconds: 30 # 表明第一次检测在容器启动后多长时间后开始
timeoutSeconds: 5 # 检测的超时时间
periodSeconds: 30 # 检查间隔时间
successThreshold: 1 # 成功门槛
failureThreshold: 5 # 失败门槛,连接失败5次,pod杀掉,重启一个新的pod
readinessProbe: # Pod 准备服务健康检查设置
httpGet:
path: /healthCheck
port: 8080
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
periodSeconds: 10
successThreshold: 1
failureThreshold: 5
#也可以用这种方法
#exec: 执行命令的方法进行监测,如果其退出码不为0,则认为容器正常
# command:
# - cat
# - /tmp/health
#也可以用这种方法
#tcpSocket: # 通过tcpSocket检查健康
# port: number
ports:
- name: http # 名称
containerPort: 8080 # 容器开发对外的端口
protocol: TCP # 协议
imagePullSecrets: # 镜像仓库拉取密钥
- name: harbor-certification
affinity: # 亲和性调试
nodeAffinity: # 节点亲和力
requiredDuringSchedulingIgnoredDuringExecution: # pod 必须部署到满足条件的节点上
nodeSelectorTerms: # 节点满足任何一个条件就可以
- matchExpressions: # 有多个选项,则只有同时满足这些逻辑选项的节点才能运行 pod
- key: beta.kubernetes.io/arch
operator: In
values:
- amd64
更多推荐
所有评论(0)