k8s 基础理论汇总

1. k8s 有哪些常用组件，他们功能是什么

•  etcd 保存了整个集群的状态；
• apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机 制；
• controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
• kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
• Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡

 

 

2. 容器有哪些优点

• 敏捷的应用程序创建和部署: 与虚拟机镜像相比，容器镜像更易用、更高效。
• 持续开发、集成和部署: 提供可靠与频繁的容器镜像构建、部署和快速简便的回滚
• 开发与运维的关注分离: 在构建/发布时即创建容器镜像，从而将应用与基础架构分离
• 开发、测试与生产环境的一致性
• 可观测：不仅显示操作系统的信息和度量，还显示应用自身的信息和度量
• 云和操作系统的分发可移植性
• 以应用为中心的管理: 从传统的硬件上部署操作系统提升到操作系统中部署应用程序。
• 松耦合、分布式、弹性伸缩、微服务: 应用程序被分成更小，更独立的模块，并可以动态管理和 部署 - 而不是运行在专用设备上的大型单体程序
• 资源隔离：可预测的应用程序性能。
• 资源利用：高效率和高密度。

3. pod 有哪些默认命名空间，作用是什么

• PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID。
• 网络命名空间（network）：Pod 中的多个容器能够访问同一个IP和端口范围。
• IPC命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
• UTS命名空间：Pod 中的多个容器共享一个主机名。
• Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes

4.  pause容器作用？

• 它是pod中Linux名称空间共享的基础
• pause容器作为你的pod中所有容器的“父容器”
• 启用了PID(进程ID)命名空间共享后，它为每个pod充当PID 1，并接收僵尸进程。子进程异常退出服务回收资源。

 5. Taints 和 tolerations 有什么区别？
　　Taints 和 tolerations 用于保证 Pod 不被调度到不合适的 Node 上，其中 Taint 应用于 Node 上，而 toleration 则应用于 Pod 上。

　　目前支持的 taint 类型

• 　　NoSchedule：新的 Pod 不调度到该 Node 上，不影响正在运行的 Pod PreferNoSchedule：
• 　　soft 版的 NoSchedule，尽量不调度到该 Node 上 NoExecute：
• 　　新的 Pod 不调度到该 Node 上，并且删除（evict）已在运行的 Pod。Pod 可 以增加一个时间（tolerationSeconds）

 6.  哪些因素会影响kube-scheduler 调度pod

• 　　　　公平调度
• 　　　　资源高效利用
• 　　　　QoS
• 　　　　affinity 和 anti-affinity 　
• 　　　　数据本地化（data locality）
• 　　　　内部负载干扰（inter-workload interference）
• 　　　　deadlines

7.  如何将pod 调度到指定节点

• 　　nodeSelector：只调度到匹配指定 label 的 Node 上
• 　　nodeAffinity：功能更丰富的 Node 选择器，比如支持集合操作
• 　　podAffinity：调度到满足条件的 Pod 所在的 Node 上

8. k8s kube-schedulerr 调度会经过哪些阶段？

• predicate：过滤不符合条件的节点
• priority：优先级排序，选择优先级最高的节点

9. predicates 有哪些 策略

• PodFitsPorts：同 PodFitsHostPorts
• PodFitsHostPorts：检查是否有 Host Ports 冲突 kube-scheduler ·
• PodFitsResources：检查 Node 的资源是否充足，包括允许的 Pod 数量、CPU、内存、GPU 个数以及其他的
• OpaqueIntResources HostName：检查 pod.Spec.NodeName 是否与候选节点一致
• MatchNodeSelector：检查候选节点的 pod.Spec.NodeSelector 是否匹配 NoVolumeZoneConflict：检查 volume zone 是否冲突
• MaxEBSVolumeCount：检查 AWS EBS Volume 数量是否过多（默认不超过 39）
• MaxGCEPDVolumeCount：检查 GCE PD Volume 数量是否过多（默认不超过 16）
• MaxAzureDiskVolumeCount：检查 Azure Disk Volume 数量是否过多（默认不超过 16）
• MatchInterPodAffinity：检查是否匹配 Pod 的亲和性要求 NoDiskConflict：检查是否存在 Volume 冲突，仅限于 GCE PD、AWS EBS、Ceph RBD 以及 ISCSI GeneralPredicates：分为 noncriticalPredicates 和 EssentialPredicates。 noncriticalPredicates 中包含 PodFitsResources，EssentialPredicates 中包含 PodFitsHost，PodFitsHostPorts 和 PodSelectorMatches。 PodToleratesNodeTaints：检查 Pod 是否容忍
• Node Taints CheckNodeMemoryPressure：检查 Pod 是否可以调度到 MemoryPressure 的节点上
• CheckNodeDiskPressure：检查 Pod 是否可以调度到 DiskPressure 的节点上
• NoVolumeNodeConflict：检查节点是否满足 Pod 所引用的 Volume 的条件

10. priorities 有哪些策略

• SelectorSpreadPriority：优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
• InterPodAffinityPriority：优先将 Pod 调度到相同的拓扑上（如同一个节点、Rack、 Zone 等）
• LeastRequestedPriority：优先调度到请求资源少的节点上 BalancedResourceAllocation：优先平衡各节点的资源使用 NodePreferAvoidPodsPriority：alpha.kubernetes.io/preferAvoidPods 字段判 断, 权重为 10000，避免其他优先级策略的影响
• NodeAffinityPriority：优先调度到匹配 NodeAffinity 的节点上
• TaintTolerationPriority：优先调度到匹配 TaintToleration 的节点上
• ServiceSpreadingPriority：尽量将同一个 service 的 Pod 分布到不同节点上，已经被 SelectorSpreadPriority 替代 [默认未使用] EqualPriority：将所有节点的优先级设置为 1[默认未使用] ImageLocalityPriority：尽量将使用大镜像的容器调度到已经下拉了该镜像的节点上 [默认 未使用] MostRequestedPriority：尽量调度到已经使用过的 Node 上，特别适用于 clusterautoscaler[默认未使用]

11. etcd数据如何备份

 

ETCDCTL_API=3 etcdctl \

 

snapshot save /data/backup/etcd-snapshot1.db \

 

--endpoints=https://127.0.0.1:2379 \

 

--cacert=/opt/KUCM00302/ca.crt \

 

  --cert=/opt/KUCM00302/etcd-client.crt\

 

  --key=/opt/KUCM00302/etcd-client.key

12.  k8s控制器有哪些？

• ReplicaSet ： 确保预期的Pod副本数量
• Deployment ： 无状态应用部署
• StatefulSet ： 有状态应用部署
• DaemonSet ： 确保所有Node运行同一个Pod
• Job ： 一次性任务
• Cronjob ： 定时任务

13.  哪些是集群级别的资源？

• Namespace： 名称空间，将对象逻辑上隔离
• Node： k8s集群节点
• Role：  角色可以用Role来定义到某个命名空间上
• ClusterRole:  ClusterRole 来定义到整个集群作用域
• RoleBinding: 角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户
• ClusterRoleBinding: 可用来在集群级别或对所有命名空间执行授权

14.  pod状态有哪些？

1) Pending:

Pod已经被创建，但还没有完成调度，或者说有一个或多个镜像正处于从远程仓库下载的过程。

处在这个阶段的Pod可能正在写数据到etcd中、调度、pull镜像或启动容器。

2) Running

该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建.

3) Succeeded

Pod中的所有的容器已经正常的执行后退出，并且不会自动重启，一般会是在部署job的时候会出现

4) Failed

Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。

5) Unkonwn

API Server无法正常获取到Pod对象的状态信息，通常是由于其无法与所在工作节点的kubelet通信所致

15. pod创建过程是什么？

• 0、kubectl apply -f pod.yaml
• 1、kubectl将yaml转换成json，提交给apiserver，apiserver将数据存储etcd
• 2、scheduler会监听到创建新pod的事件，根据pod属性调度到指定节点，并且给pod打个标签具体是哪个节点
• 3、apiserver拿到调度的结果并写到etcd中
• 4、kubelet从apiserver获取分配到我节点的pod
• 5、kubelet调用docker sock创建容器
• 6、docker根据kubelet需求创建完容器后将容器状态回报给kubelet
• 7、kubelet会将pod状态更新到apiserver
• 8、apiserer将状态数据写到etcd
• 9、kubectl get pods

 16. pod重启策略有哪些？

 

• 1）Always：当容器终止退出后，总是重启容器，默认策略
• 2） OnFailure：当容器异常退出（退出状态码非0）时，才重启容器
• 3） Never：当容器终止退出，从不重启容器。

17. 资源探针有哪些？

1）livenessProbe（存活检查）

如果检查失败，将杀死容器，根据Pod的restartPolicy来操作

2）readinessProbe（就绪检查）

如果检查失败，Kubernetes会把Pod从service endpoints中剔除。

18. kubeconfig文件包含什么内容，用途是什么？

export KUBE_APISERVER="https://172.20.0.113:6443"

# 设置集群参数

kubectl config set-cluster kubernetes \

   --certificate-authority=/etc/kubernetes/ssl/ca.pem \

   --embed-certs=true \

   --server=${KUBE_APISERVER}

# 设置客户端认证参数

kubectl config set-credentials admin \

   --client-certificate=/etc/kubernetes/ssl/admin.pem \

   --embed-certs=true \

   --client-key=/etc/kubernetes/ssl/admin-key.pem

# 设置上下文参数

kubectl config set-context kubernetes \

   --cluster=kubernetes \

   --user=admin

# 设置默认上下文

kubectl config use-context Kubernetes

19.  RBAC中role和clusterrole区别，rolebinding和 clusterrolebinding区别？ 

•  Role：  角色可以用 Role 来定义到某个命名空间上
• ClusterRole:  ClusterRole 来定义到整个集群作用域
• RoleBinding: 角色绑定（RoleBinding）是将角色中定义的权限赋予一个或者一组用户
• ClusterRoleBinding: 可用来在集群级别或对所有命名空间执行授权

 

20.  pv pvc用途，容器挂载存储整个流程是什么？

Pv： 持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者 使用存储类（Storage Class）来动态供应。

pvc: 持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。

容器挂载存储流程：

静态pv：

• 1． K8s 管理员创建pv（静态pv） 
• 2． 用户创建 pvc，并绑定到pv（实际使用pv那块存储资源）
• 3． 用户创建应用并绑定pvc。

动态pv：

• 1. 使用k8s存储类storage class 创建存储资源池
• 2. 用户创建 PVC，此处 PVC 的 storageClassName 指定为上面 NFS 的 storageclass 名称（storageclass 会动态创建pv, 并与 PVC 已绑定。）
• 4. 用户创建应用，并使用第二步创建的 PVC，同静态创建存储卷的第三步

21. pv 回收策略有哪些？

 

• Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
• Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。
• Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等
• 可以通过persistentVolumeReclaimPolicy：Recycle字段配置

22.  k8s 镜像的拉取策略有哪些？

• 　　Always：总是拉取  --> imagePullPolicy: Always
•       IfNotPresent：默认值,本地有则使用本地镜像,不拉取 --->   imagePullPolicy: IfNotPresent
•       Never：只使用本地镜像，从不拉取  -----> imagePullPolicy: Never

23. PV哪些的状态

 

• Available：可用，没有被PVC绑定的空闲资源
• Bound：已绑定，已经被PVC绑定
• Released：已释放，PVC被删除，但是资源还未被重新使用
• Failed：失败，自动回收失败

25. 重启失败的pod 如何查看日志

kubectl logs  --tail 100 --previous -nxxx xxx