K8s面试题

为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力，多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力

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会自动创建外部负载均衡器，将外部的流量负载均衡至相关联的pod

4.externalName：适用需要外部服务的场景，将内部的请求转发到外部的DNS

Q5：Kubernetes网络模型的核心原则是什么？

核心原则是每个pod一个IP，确保pod之间通信像同一局域网内一样简单，且不依赖于pod所在的节点，网络插件（flannel、calico实现此模型）

flannel和calico的区别：（重点会问）

特性 Flannel Calico
原理使用Overlay网络，在底层物理网络之上
创建虚拟的网络层基于L3即网络层路由，直接在底层网络
上路由
性能较低 (由于 overlay 网络开销) 较高 (直接 L3 路由)
安装和配置简单易用相对复杂
网络策略支持基本支持高级支持 (细粒度访问控制)
适用场景小规模集群，测试环境大规模生产环境，要求高性能和安全性
依赖 etcd，flanneld BGP，Felix
calico补充：
BGP是一种网络架构，主要依赖于第 3 层（网络层）的路由协议，尤其是 BGP（边界网关协议，Border Gateway Protocol），用于管理网络中不同子网之间的路由
支持的高级网络策略有：
1.细粒度的流量控制：允许自定义哪些pod之间可以互相通信；自定义允许哪些pod可访问特定的服务
2.ingress和egress流量控制：控制ingress入站流量和egress出站流量
3.DNS策略：允许你控制pod可解析哪些DNS
4.支持多集群环境等等

特性	Flannel	Calico
原理	使用Overlay网络，在底层物理网络之上创建虚拟的网络层	基于L3即网络层路由，直接在底层网络上路由
性能	较低 (由于 overlay 网络开销)	较高 (直接 L3 路由)
安装和配置	简单易用	相对复杂
网络策略支持	基本支持	高级支持 (细粒度访问控制)
适用场景	小规模集群，测试环境	大规模生产环境，要求高性能和安全性
依赖	etcd，flanneld	BGP，Felix

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.yaml

kubectl 命令行工具支持多种不同的方式来创建和管理 Kubernetes对象
1.指令式命令：kubectl create deployment nginx --image nginx

2.声明式文件：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