K8s面试题——基础篇2

文章目录

[一、简述 Kubernetes 如何保证集群的安全性](#一、简述 Kubernetes 如何保证集群的安全性)
[二、简述 Kubernetes 准入机制](#二、简述 Kubernetes 准入机制)
[三、简述 Kubernetes RBAC 及其特点（优势）](#三、简述 Kubernetes RBAC 及其特点（优势）)
[四、简述 Kubernetes Secret 作用](#四、简述 Kubernetes Secret 作用)
[五、简述 Kubernetes Secret 有哪些使用方式](#五、简述 Kubernetes Secret 有哪些使用方式)
[六、简述 Kubernetes PodSecurityPolicy 机制](#六、简述 Kubernetes PodSecurityPolicy 机制)
[七、简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略](#七、简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略)
[八、简述 Kubernetes 网络模型](#八、简述 Kubernetes 网络模型)
[九、简述 Kubernetes CNI 模型](#九、简述 Kubernetes CNI 模型)
[十、简述 Kubernetes 网络策略](#十、简述 Kubernetes 网络策略)
[十一、简述 Kubernetes 网络策略原理](#十一、简述 Kubernetes 网络策略原理)
[十二、简述 Kubernetes 中 flannel 的作用](#十二、简述 Kubernetes 中 flannel 的作用)
[十三、简述 Kubernetes Calico 网络组件实现原理](#十三、简述 Kubernetes Calico 网络组件实现原理)
[十四、简述 Kubernetes 共享存储的作用](#十四、简述 Kubernetes 共享存储的作用)
[十五、简述 Kubernetes 数据持久化的方式有哪些](#十五、简述 Kubernetes 数据持久化的方式有哪些)
[十六、简述 Kubernetes PV 和 PVC](#十六、简述 Kubernetes PV 和 PVC)
[十七、简述 Kubernetes PV 生命周期内的阶段](#十七、简述 Kubernetes PV 生命周期内的阶段)
[十八、简述 Kubernetes 所支持的存储供应模式](#十八、简述 Kubernetes 所支持的存储供应模式)
[十九、简述 Kubernetes CSI 模型](#十九、简述 Kubernetes CSI 模型)
[二十、简述 Kubernetes Worker 节点加入集群的过程](#二十、简述 Kubernetes Worker 节点加入集群的过程)
[二十一、简述 Kubernetes Pod 如何实现对节点的资源控制](#二十一、简述 Kubernetes Pod 如何实现对节点的资源控制)
[二十二、简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度](#二十二、简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度)
[二十三、简述 Kubernetes Metric Service](#二十三、简述 Kubernetes Metric Service)
[二十四、简述 Kubernetes 中，如何使用 EFK 实现日志的统一管理](#二十四、简述 Kubernetes 中，如何使用 EFK 实现日志的统一管理)
[二十五、简述 Kubernetes 如何进行优雅的节点关机维护](#二十五、简述 Kubernetes 如何进行优雅的节点关机维护)
[二十六、简述 Kubernetes 集群联邦](#二十六、简述 Kubernetes 集群联邦)
[二十七、简述 Helm 及其优势](#二十七、简述 Helm 及其优势)
[二十八、什么是 Headless Service](#二十八、什么是 Headless Service)
[二十九、简述K8s 常用的 CNI 网络插件（calico && flannel）的工作原理和区别](#二十九、简述K8s 常用的 CNI 网络插件（calico && flannel）的工作原理和区别)
[三十、Worker 节点宕机，简述 Pods 驱逐流程](#三十、Worker 节点宕机，简述 Pods 驱逐流程)
[三十一、简述 kube-proxy 的三种工作模式和原理](#三十一、简述 kube-proxy 的三种工作模式和原理)
[三十二、Docker 的网络通信模式](#三十二、Docker 的网络通信模式)

一、简述 Kubernetes 如何保证集群的安全性

Kubernetes 通过一系列机制来实现集群的安全控制，主要有如下不同的维度：

基础设施方面：保证容器与其所在宿主机的隔离；

权限方面：

最小权限原则：合理限制所有组件的权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它的权限范围。

用户权限：划分普通用户和管理员的角色。

集群方面：

API Server 的认证授权：Kubernetes 集群中所有资源的访问和变更都是通过 Kubernetes API Server 来实现的，因此需要建议采用更安全的 HTTPS或 Token 来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节。

API Server 的授权管理：通过授权策略来决定一个 API 调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的 RBAC 方式来提升集群安全授权。

敏感数据引入 Secret 机制：对于集群敏感数据建议使用 Secret 方式进行保护。

AdmissionControl（准入机制）：对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。

二、简述 Kubernetes 准入机制

在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的 error 信息。

准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。常用组件（控制代码）如下：

AlwaysAdmit：允许所有请求

AlwaysDeny：禁止所有请求，多用于测试环境。

ServiceAccount：它将 serviceAccounts 实现了自动化，它会辅助 serviceAccount做一些事情，比如如果 pod 没有 serviceAccount 属性，它会自动添加一个 default，并确保 pod 的 serviceAccount 始终存在。

LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在 namespace 中 LimitRange 对象中。

NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的 namespace，则这个请求被拒绝。

三、简述 Kubernetes RBAC 及其特点（优势）

RBAC 是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。

相对于其他授权模式，RBAC 具有如下优势：

对集群中的资源和非资源权限均有完整的覆盖。

整个 RBAC 完全由几个 API 对象完成，同其他 API 对象一样，可以用 kubectl或 API 进行操作。

可以在运行时进行调整，无须重新启动 API Server。

四、简述 Kubernetes Secret 作用

Secret 对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys 等信息。

将这些私密信息放在 Secret 对象中比直接放在 Pod 或 Docker Image 中更安全，也更便于使用和分发。

五、简述 Kubernetes Secret 有哪些使用方式

创建完 secret 之后，可通过如下三种方式使用：

在创建 Pod 时，通过为 Pod 指定 Service Account 来自动使用该 Secret。

通过挂载该 Secret 到 Pod 来使用它。

在 Docker 镜像下载时使用，通过指定 Pod 的 spc.ImagePullSecrets 来引用它。

六、简述 Kubernetes PodSecurityPolicy 机制

Kubernetes PodSecurityPolicy 是为了更精细地控制 Pod 对资源的使用方式以及提升安全策略。

在开启 PodSecurityPolicy 准入控制器后，Kubernetes 默认不允许创建任何 Pod，需要创建 PodSecurityPolicy 策略和相应的 RBAC 授权策略（Authorizing Policies），Pod才能创建成功。

七、简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略

在 PodSecurityPolicy 对象中可以设置不同字段来控制 Pod 运行时的各种安全策略，常见的有：

特权模式：privileged 是否允许 Pod 以特权模式运行。

宿主机资源：控制 Pod 对宿主机资源的控制，如 hostPID：是否允许 Pod 共享宿主机的进程空间。

用户和组：设置运行容器的用户 ID（范围）或组（范围）。

提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限，通常在设置非 root 用户（MustRunAsNonRoot）时进行设置。

SELinux：进行 SELinux 的相关配置。

八、简述 Kubernetes 网络模型

Kubernetes 网络模型中每个 Pod 都拥有一个独立的 IP 地址，并假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个 Node（宿主机）中，都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。

同时为每个 Pod 都设置一个 IP 地址的模型使得同一个 Pod 内的不同容器会共享同一个网络命名空间，也就是同一个 Linux 网络协议栈。这就意味着同一个 Pod 内的容器可以通过 localhost 来连接对方的端口。

在 Kubernetes 的集群里，IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈（相当于一个网络命名空间，它们的 IP 地址、网络设备、配置等都是共享的）。

九、简述 Kubernetes CNI 模型

CNI 提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对 CNI 接口进行实现。CNI 仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。在 CNI 模型中只涉及两个概念：容器和网络。

容器（Container）：是拥有独立 Linux 网络命名空间的环境，例如使用 Docker或 rkt 创建的容器。容器需要拥有自己的 Linux 网络命名空间，这是加入网络的必要条件。

网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP 地址，可以是容器、物理机或者其他网络设备（比如路由器）等。

对容器网络的设置和操作都通过插件（Plugin）进行具体实现，CNI 插件包括两种类型：CNI Plugin 和 IPAM（IP Address Management）Plugin。

CNI Plugin 负责为容器配置网络资源，IPAM Plugin 负责对容器的 IP 地址进行分配和管理。

IPAM Plugin 作为 CNI Plugin 的一部分，与 CNI Plugin 协同工作。

十、简述 Kubernetes 网络策略

为实现细粒度的容器间网络访问隔离策略，Kubernetes 引入 Network Policy。

Network Policy 的主要功能是对 Pod 间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端 Pod 列表。Network Policy 定义网络策略，配合策略控制器（PolicyController）进行策略的实现。

十一、简述 Kubernetes 网络策略原理

Network Policy 的工作原理主要为：policy controller 需要实现一个 API Listener，监听用户设置的 Network Policy 定义，并将网络访问规则通过各 Node 的 Agent 进行实际设置（Agent 则需要通过 CNI 网络插件实现）。

十二、简述 Kubernetes 中 flannel 的作用

Flannel 可以用于 Kubernetes 底层网络的实现，主要作用有：

它能协助 Kubernetes，给每一个 Node 上的 Docker 容器都分配互相不冲突的 IP地址。

它能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

十三、简述 Kubernetes Calico 网络组件实现原理

Calico 是一个基于 BGP 的纯三层的网络方案，与 OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。

Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发。每个 vRouter 都通过 BGP 协议把在本节点上运行的容器的路由信息向整个 Calico 网络广播，并自动设置到达其他节点的路由转发规则。

Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。Calico 节点组网时可以直接利用数据中心的网络结构（L2 或者 L3），不需要额外的 NAT、隧道或者 Overlay Network，没有额外的封包解包，能够节约 CPU 运算，提高网络效率。

十四、简述 Kubernetes 共享存储的作用

Kubernetes 对于有状态的容器应用或者对数据需要持久化的应用，因此需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。

十五、简述 Kubernetes 数据持久化的方式有哪些

EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由 Pod 内保部映射到宿主机上。类似于 docker 中的 manager volume。

场景：

只需要临时将数据保存在磁盘上，比如在合并/排序算法中；

作为两个容器的共享存储。

特性：

同个 pod 里面的不同容器，共享同一个持久化目录，当 pod 节点删除时，volume 的数据也会被删除。

emptyDir 的数据持久化的生命周期和使用的 pod 一致，一般是作为临时存储使用。

Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于 docker 中的 bind mount 挂载方式。

特性：增加了 pod 与节点之间的耦合。

PersistentVolume（简称 PV）：如基于 NFS 服务的 PV，也可以基于 GFS 的 PV。它的作用是统一数据持久化目录，方便管理。

十六、简述 Kubernetes PV 和 PVC

PV 是对底层网络共享存储的抽象，将共享存储定义为一种"资源"。

PVC 则是用户对存储资源的一个"申请"。

十七、简述 Kubernetes PV 生命周期内的阶段

某个 PV 在生命周期中可能处于以下 4 个阶段（Phaes）之一。

Available：可用状态，还未与某个 PVC 绑定。

Bound：已与某个 PVC 绑定。

Released：绑定的 PVC 已经删除，资源已释放，但没有被集群回收。

Failed：自动资源回收失败。

十八、简述 Kubernetes 所支持的存储供应模式

Kubernetes 支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。

静态模式：集群管理员手工创建许多 PV，在定义 PV 时需要将后端存储的特性进行设置。

动态模式：集群管理员无须手工创建 PV，而是通过 StorageClass 的设置对后端存储进行描述，标记为某种类型。此时要求 PVC 对存储的类型进行声明，系统将自动完成 PV 的创建及与 PVC 的绑定。

十九、简述 Kubernetes CSI 模型

Kubernetes CSI 是 Kubernetes 推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务。CSI 使得存储提供方的代码能和 Kubernetes 代码彻底解耦，部署也与 Kubernetes核心组件分离，显然，存储插件的开发由提供方自行维护，就能为 Kubernetes 用户提供更多的存储功能，也更加安全可靠。

CSI 包括 CSI Controller 和 CSI Node：

CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。

CSI Node 的主要功能是对主机（Node）上的 Volume 进行管理和操作。

二十、简述 Kubernetes Worker 节点加入集群的过程

通常需要对 Worker 节点进行扩容，从而将应用系统进行水平扩展。主要过程如下：

在该 Node 上安装 Docker、kubelet 和 kube-proxy 服务；

然后配置 kubelet 和 kubeproxy 的启动参数，将 Master URL 指定为当前Kubernetes 集群 Master 的地址，最后启动这些服务；

通过 kubelet 默认的自动注册机制，新的 Worker 将会自动加入现有的Kubernetes 集群中；

Kubernetes Master 在接受了新 Worker 的注册之后，会自动将其纳入当前集群的调度范围。

二十一、简述 Kubernetes Pod 如何实现对节点的资源控制

Kubernetes 集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。

当前 Kubernetes 集群中的计算资源主要包括 CPU、GPU及 Memory。CPU 与 Memory 是被 Pod 使用的，因此在配置 Pod 时可以通过参数 CPU Request 及 Memory Request 为其中的每个容器指定所需使用的 CPU 与 Memory 量，Kubernetes 会根据 Request 的值去查找有足够资源的 Node 来调度此 Pod。

通常，一个程序所使用的 CPU 与 Memory 是一个动态的量，确切地说，是一个范围，跟它的负载密切相关：负载增加时，CPU 和 Memory 的使用量也会增加。

二十二、简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度

当一个 Pod 创建成功时，Kubernetes 调度器（Scheduler）会为该 Pod 选择一个节点来执行。对于每种计算资源（CPU 和 Memory）而言，每个节点都有一个能用于运行 Pod的最大容量值。调度器在调度时，首先要确保调度后该节点上所有 Pod 的 CPU 和内存的 Requests 总和，不超过该节点能提供给 Pod 使用的 CPU 和 Memory 的最大容量值。

二十三、简述 Kubernetes Metric Service

在 Kubernetes 从 1.10 版本后采用 Metrics Server 作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括 Node、Pod 的 CPU 和内存使用指标。

对其他自定义指标（Custom Metrics）的监控则由 Prometheus 等组件来完成。

二十四、简述 Kubernetes 中，如何使用 EFK 实现日志的统一管理

在 Kubernetes 集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，通常采用 EFK 实现。

EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合，其各组件功能如下：

Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；

Fluentd：负责从 Kubernetes 搜集日志，每个 node 节点上面的 fluentd 监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给 Elasticsearch；

Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。

通过在每台 node 上部署一个以 DaemonSet 方式运行的 fluentd 来收集每台 node 上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers 和/var/log 目录挂载到 Pod 中，然后 Pod 会在 node 节点的/var/log/pods 目录中创建新的目录，可以区别不同的容器日志输出，该目录下有一个日志文件链接到/var/lib/docker/contianers 目录下的容器日志输出。

二十五、简述 Kubernetes 如何进行优雅的节点关机维护

由于 Kubernetes 节点运行大量 Pod，因此在进行关机维护之前，建议先使用 kubectldrain 将该节点的 Pod 进行驱逐，然后进行关机维护。

二十六、简述 Kubernetes 集群联邦

Kubernetes 集群联邦可以将多个 Kubernetes 集群作为一个集群进行管理。

因此，可以在一个数据中心/云中创建多个 Kubernetes 集群，并使用集群联邦在一个地方控制/管理所有集群。

二十七、简述 Helm 及其优势

Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的 apt、Centos 中使用的yum 或者 Python 中的 pip 一样。Helm 能够将一组 K8S 资源打包统一管理, 是查找、共享和使用为 Kubernetes 构建的软件的最佳方式。

Helm 中通常每个包称为一个 Chart，一个 Chart 是一个目录（一般情况下会将目录进行打包压缩，形成 name-version.tgz 格式的单一文件，方便传输和存储）。

在 Kubernetes 中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。使用 helm 则具有如下优势：

统一管理、配置和更新这些分散的 k8s 的应用资源文件；

分发和复用一套应用模板；

将应用的一系列资源当做一个软件包管理。

对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。

对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

二十八、什么是 Headless Service

Headless Service 类似于"普通"服务，但没有群集 IP。此服务使您可以直接访问 pod，而无需通过代理访问它。

二十九、简述K8s 常用的 CNI 网络插件（calico && flannel）的工作原理和区别

calico 的工作原理：

calico 根据 iptables 规则进行路由转发，并没有进行封包，解包的过程，这和 flannel比起来效率就会快多。

calico 包括如下重要组件：Felix，etcd，BGP Client，BGP Route Reflector。下面分别说明一下这些组件。

Felix：主要负责路由配置以及 ACLS 规则的配置以及下发，它存在在每个 node 节点上。

etcd：分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性，可以与 kubernetes 共用；

BGPClient(BIRD), 主要负责把 Felix 写入 kernel 的路由信息分发到当前 Calico 网络，确保 workload 间的通信的有效性；

BGPRoute Reflector(BIRD), 大规模部署时使用，摒弃所有节点互联的 mesh 模式，通过一个或者多个 BGPRoute Reflector 来完成集中式的路由分发。

通过将整个互联网的可扩展 IP 网络原则压缩到数据中心级别，Calico 在每一个计算节点利用 Linuxkernel 实现了一个高效的 vRouter 来负责数据转发，而每个 vRouter 通过BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播，小规模部署可以直接互联，大规模下可通过指定的 BGProute reflector 来完成。这样保证最终所有的 workload 之间的数据流量都是通过 IP 包的方式完成互联的。

Flannel 的工作原理：

Flannel 实质上是一种"覆盖网络(overlay network)"，也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信，目前已经支持 UDP、VxLAN、AWS VPC 和 GCE 路由等数据转发方式。默认的节点间数据通信方式是 UDP 转发。

数据从源容器中发出后，经由所在主机的 docker0 虚拟网卡转发到 flannel0 虚拟网卡（先可以不经过 docker0 网卡，使用 cni 模式），这是个 P2P 的虚拟网卡，flanneld 服务监听在网卡的另外一端。

Flannel 通过 Etcd 服务维护了一张节点间的路由表，详细记录了各节点子网网段。

源主机的 flanneld 服务将原本的数据内容 UDP 封装后根据自己的路由表投递给目的节点的 flanneld 服务，数据到达以后被解包，然后直接进入目的节点的 flannel0 虚拟网卡，然后被转发到目的主机的 docker0 虚拟网卡，最后就像本机容器通信一下的有 docker0路由到达目标容器。

flannel 在进行路由转发的基础上进行了封包解包的操作，这样浪费了 CPU 的计算资源。

三十、Worker 节点宕机，简述 Pods 驱逐流程

在 Kubernetes 集群中，当节点由于某些原因（网络、宕机等）不能正常工作时会被认定为不可用状态（Unknown 或者 False 状态），当时间超过了 pod-eviction-timeout 值时，那么节点上的所有 Pod 都会被节点控制器计划删除。

Kubernetes 集群中有一个节点生命周期控制器：node_lifecycle_controller.go。它会与每一个节点上的 kubelet 进行通信，以收集各个节点以及节点上容器的相关状态信息。当超出一定时间后不能与 kubelet 通信，那么就会标记该节点为 Unknown 状态。并且节点生命周期控制器会自动创建代表状况的污点，用于防止调度器调度 pod 到该节点。

那么 Unknown 状态的节点上已经运行的 pod 会怎么处理呢？节点上的所有 Pod都会被污点管理器（taint_manager.go）计划删除。而在节点被认定为不可用状态到删除节点上的 Pod 之间是有一段时间的，这段时间被称为容忍度。

如果在不配置的情况下，Kubernetes 会自动给 Pod 添加一个 key 为node.kubernetes.io/not-ready 的容忍度并配置 tolerationSeconds=300，同样，Kubernetes会给 Pod 添加一个 key 为 node.kubernetes.io/unreachable 的容忍度并配置tolerationSeconds=300。

当到了删除 Pod 时，污点管理器会创建污点标记事件，然后驱逐 pod 。这里需要注意的是由于已经不能与 kubelet 通信，所以该节点上的 Pod 在管理后台看到的是处于灰色标记，但是此时如果去获取 pod 的状态其实还是处于 Running 状态。每种类型的资源都有相应的资源控制器（Controller），例如：deployment_controller.go、stateful_set_control.go。每种控制器都在监听资源变化，从而做出相应的动作执行。
deployment 控制器在监听到 Pod 被驱逐后会创建一个新的 Pod 出来，但是 Statefulset控制器并不会创建出新的 Pod，原因是因为它可能会违反 StatefulSet 固有的至多一个的语义，可能出现具有相同身份的多个成员，这将可能是灾难性的，并且可能导致数据丢失。

三十一、简述 kube-proxy 的三种工作模式和原理

userspace 模式：

该模式下 kube-proxy 会为每一个 Service 创建一个监听端口。发向 Cluster IP 的请求被Iptables 规则重定向到 Kube-proxy 监听的端口上，Kube-proxy 根据 LB 算法选择一个提供服务的 Pod 并和其建立链接，以将请求转发到 Pod 上。

该模式下，Kube-proxy 充当了一个四层 Load balancer 的角色。由于 kube-proxy 运行在userspace 中，在进行转发处理时会增加两次内核和用户空间之间的数据拷贝，效率较另外两种模式低一些；好处是当后端的 Pod 不可用时，kube-proxy 可以重试其他 Pod。

iptables 模式：

为了避免增加内核和用户空间的数据拷贝操作，提高转发效率，Kube-proxy 提供了iptables 模式。在该模式下，Kube-proxy 为 service 后端的每个 Pod 创建对应的 iptables规则，直接将发向 Cluster IP 的请求重定向到一个 Pod IP。

该模式下 Kube-proxy 不承担四层代理的角色，只负责创建 iptables 规则。该模式的优点是较 userspace 模式效率更高，但不能提供灵活的 LB 策略，当后端 Pod 不可用时也无法进行重试。

该模式和 iptables 类似，kube-proxy 监控 Pod 的变化并创建相应的 ipvs rules。ipvs 也是在 kernel 模式下通过 netfilter 实现的，但采用了 hash table 来存储规则，因此在规则较多的情况下，Ipvs 相对 iptables 转发效率更高。除此以外，ipvs 支持更多的 LB 算法。如果要设置 kube-proxy 为 ipvs 模式，必须在操作系统中安装 IPVS 内核模块。

三十二、Docker 的网络通信模式

host 模式，使用 --net=host 指定。

和宿主机共用一个 Network Namespace。容器将不会虚拟出自己的网卡，配置自己的 IP等，而是使用宿主机的 IP 和端口。

container 模式，使用 --net=container:NAMEorID 指定。

指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。

none 模式，使用 --net=none 指定。

告诉 docker 将新容器放到自己的网络堆栈中，但是不要配置它的网络。

bridge 模式，使用 --net=bridge 指定，默认设置。

bridge 模式是 Docker 默认的网络设置，此模式会为每一个容器分配 Network Namespace、设置 IP 等，并将一个主机上的 Docker 容器连接到一个虚拟网桥上。