1.简述 kube-proxy ipvs 原理？
IPVS 在 Kube.NETes1.11 中升级为 GA 稳定版。IPVS 则专门用于高性能负载均衡，并使用更高效的数据结构（Hash 表），允许几乎无限的规模扩张，因此被 kube-proxy 采纳为最新模式。
在 IPVS 模式下，使用 iptables 的扩展 ipset，而不是直接调用 iptables 来生成规则链。iptables 规则链是一个线性的数据结构，ipset 则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配。
可以将 ipset 简单理解为一个 IP（段）的集合，这个集合的内容可以是 IP 地址、IP 网段、端口等，iptables 可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少 iptables 规则的数量，从而减少性能损耗。
2.简述 kube-proxy ipvs 和 iptables 的异同？
iptables 与 IPVS 都是基于 Netfilter 实现的，但因为定位不同，二者有着本质的差别：iptables 是为防火墙而设计的；IPVS 则专门用于高性能负载均衡，并使用更高效的数据结构（Hash 表），允许几乎无限的规模扩张。
与 iptables 相比，IPVS 拥有以下明显优势：
1、为大型集群提供了更好的可扩展性和性能；
2、支持比 iptables 更复杂的复制均衡算法（最小负载、最少连接、加权等）；
3、支持服务器健康检查和连接重试等功能；
4、可以动态修改 ipset 的集合，即使 iptables 的规则正在使用这个集合。
3.简述 Kubernetes 中什么是静态 Pod？
静态 pod 是由 kubelet 进行管理的仅存在于特定 Node 的 Pod 上，他们不能通过 API Server 进行管理，无法与 ReplicationController、Deployment 或者DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检查。静态 Pod 总是由kubelet 进行创建，并且总是在 kubelet 所在的 Node 上运行。
4.简述 Kubernetes 中 Pod 可能位于的状态？
● Pending：API Server 已经创建该 Pod，且 Pod 内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。
● Running：Pod 内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
● Succeeded：Pod 内所有容器均成功执行退出，且不会重启。
● FAIled：Pod 内所有容器均已退出，但至少有一个容器退出为失败状态。
● Unknown：由于某种原因无法获取该 Pod 状态，可能由于网络通信不畅导致。
5.简述 Kubernetes 创建一个 Pod 的主要流程？
Kubernetes 中创建一个 Pod 涉及多个组件之间联动，主要流程如下：
1、客户端提交 Pod 的配置信息（可以是 yaml 文件定义的信息）到 kube-apiserver。
2、Apiserver 收到指令后，通知给 controller-manager 创建一个资源对象。
3、Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据中心中。
4、Kube-scheduler 检测到 pod 信息会开始调度预选，会先过滤掉不符合 Pod 资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行 pod 的节点，然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。
5、Kubelet 根据 scheduler 发来的资源配置单运行 pod，运行成功后，将 pod 的运行信息返回给 scheduler，scheduler 将返回的 pod 运行状况的信息存储到 etcd 数据中心。
6.简述 Kubernetes 中 Pod 的重启策略？
Pod 重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 RestartPolicy 的设置来进行相应操作。
Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。
● Always：当容器失效时，由 kubelet 自动重启该容器；
● OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器；
● Never：不论容器运行状态如何，kubelet 都不会重启该容器。
同时 Pod 的重启策略与控制方式关联，当前可用于管理 Pod 的控制器包括ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（静态 Pod）。
不同控制器的重启策略限制如下：
● RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行；
● Job：OnFailure 或 Never，确保容器执行完成后不再重启；
● kubelet：在 Pod 失效时重启，不论将 RestartPolicy 设置为何值，也不会对 Pod 进行健康检查。
7.简述 Kubernetes 中 Pod 的健康检查方式？
对 Pod 的健康检查可以通过两类探针来检查：LivenessProbe 和ReadinessProbe。
● LivenessProbe 探针：用于判断容器是否存活（running 状态），如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针，kubelet 认为该容器的 LivenessProbe 探针返回值用于是“Success”。
● ReadineeProbe 探针：用于判断容器是否启动完成（ready 状态）。如果 ReadinessProbe 探针探测到失败，则 Pod 的状态将被修改。Endpoint Controller 将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 Eenpoint。
● startupProbe 探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针 kill 掉。
8.简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式？
kubelet 定期执行 LivenessProbe 探针来诊断容器的健康状态，通常有以下三种方式：
● ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器健康。
● TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP 连接，则表明容器健康。
● HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响应的状态码大于等于 200 且小于 400，则表明容器健康。
9.简述 Kubernetes Pod 的常见调度方式？
Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式：
●Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
●NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。
● NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前有两种节点亲和力表达：
●requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。
●preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。
●Taints 和 Tolerations（污点和容忍）
●Taint：使 Node 拒绝特定 Pod 运行；
● Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。
10.简述Kubernetes初始化容器（init container）？
init container 的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个 init container 时，将按顺序逐个运行，并且只有前一个 init container 运行成功后才能运行后一个 init container。当所有 init container 都成功运行后，Kubernetes 才会初始化 Pod 的各种信息，并开始创建和运行应用容器。
11.简述 Kubernetes deployment 升级过程？
● 初始创建 Deployment 时，系统创建了一个 ReplicaSet，并按用户的需求创建了对应数量的 Pod 副本。
● 当更新 Deployment 时，系统创建了一个新的 ReplicaSet，并将其副本数量扩展到 1，然后将旧 ReplicaSet 缩减为 2。
● 之后，系统继续按照相同的更新策略对新旧两个 ReplicaSet 进行逐个调整。
● 最后，新的 ReplicaSet 运行了对应个新版本 Pod 副本，旧的 ReplicaSet 副本数量则缩减为 0。
12.简述 Kubernetes deployment 升级策略？
在 Deployment 的定义中，可以通过 spec.strategy 指定 Pod 更新的策略，目前支持两种策略：Recreate（重建）和 RollingUpdate（滚动更新），默认值为 RollingUpdate。
● Recreate：设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod时，会先杀掉所有正在运行的 Pod，然后创建新的 Pod。
● RollingUpdate：设置 spec.strategy.type=RollingUpdate，表示 Deployment会以滚动更新的方式来逐个更新 Pod。同时，可以通过设置spec.strategy.rollingUpdate 下的两个参数（maxUnavailable 和 maxSurge）来控制滚动更新的过程。
13.简述 Kubernetes DaemonSet 类型的资源特性？
DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行，并且每个节点只能运行一个 pod，这是它和 deployment 资源对象的最大也是唯一的区别。因此， 在定义 yaml 文件中，不支持定义 replicas。
它的一般使用场景如下：
● 在去做每个节点的日志收集工作。
● 监控每个节点的的运行状态。
14.简述 Kubernetes 自动扩容机制？
Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器实现基于 CPU 使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能指标，并与 HPA 资源对象中的扩缩容条件进行对比，在满足条件时对 Pod 副本数量进行调整。
● HPA 原理
Kubernetes 中的某个 Metrics Server（Heapster 或自定义 Metrics Server）持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API（Heapster 的API 或聚合 API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标 Pod 副本数量。
当目标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器 （Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。
15.简述 Kubernetes Service 类型？
通过创建 Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址， 并且将请求负载分发到后端的各个容器应用上。其主要类型有：
● ClusterIP：虚拟的服务 IP 地址，该地址用于 Kubernetes 集群内部的 Pod 访问， 在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发；
● NodePort：使用宿主机的端口，使能够访问各 Node 的外部客户端通过 Node 的 IP 地址和端口号就能访问服务；
● LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在 spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址，通常用于公有云。
16.简述 Kubernetes Service 分发后端的策略？
Service 负载分发的策略有：RoundRobin 和 SessionAffinity：
● RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个 Pod 上。
● SessionAffinity：基于客户端 IP 地址进行会话保持的模式，即第 1 次将某个客户端发起的请求转发到后端的某个 Pod 上，之后从相同的客户端发起的请求都将被转发到后端相同的 Pod 上。
17.简述 Kubernetes Headless Service？
在某些应用场景中，若需要人为指定负载均衡器，不使用 Service 提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes 提供了Headless Service 来实现这种功能，即不为 Service 设置 ClusterIP（入口 IP 地址）， 仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。
18.简述 Kubernetes 外部如何访问集群内的服务？
对于 Kubernetes，集群外的客户端默认情况，无法通过 Pod 的 IP 地址或者 Service 的虚拟 IP 地址:虚拟端口号进行访问。通常可以通过以下方式进行访问 Kubernetes 集群内的服务：
● 映射 Pod 到物理机：将 Pod 端口号映射到宿主机，即在 Pod 中采用 hostPort 方式，以使客户端应用能够通过物理机访问容器应用。
● 映射 Service 到物理机：将 Service 端口号映射到宿主机，即在 Service 中采用 nodePort 方式，以使客户端应用能够通过物理机访问容器应用。
● 映射 Sercie 到 LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。
19.简述 Kubernetes ingress？
Kubernetes 的 Ingress 资源对象，用于将不同 URL 的访问请求转发到后端不同的 Service，以实现 HTTP 层的业务路由机制。
Kubernetes 使用了 Ingress 策略和 Ingress Controller，两者结合并实现了一个完整的 Ingress 负载均衡器。使用 Ingress 进行负载分发时，Ingress Controller 基于 Ingress 规则将客户端请求直接转发到 Service 对应的后端 Endpoint（Pod）上，从而跳过 kube-proxy 的转发功能，kube-proxy 不再起作用，全过程为：ingress controller + ingress 规则 ----> services。
同时当 Ingress Controller 提供的是对外服务，则实际上实现的是边缘路由器的功能。
20.简述 Kubernetes 镜像的下载策略？
K8s 的镜像下载策略有三种：Always、Never、IFNotPresent。
● Always：镜像标签为 latest 时，总是从指定的仓库中获取镜像。
● Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像。
● IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。默认的镜像下载策略是：当镜像标签是 latest 时，默认策略是 Always；当镜像标签是自定义时（也就是标签不是 latest），那么默认策略是 IfNotPresent。
21.简述 Kubernetes 的负载均衡器？
负载均衡器是暴露服务的最常见和标准方式之一。
根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器。
