关于kubernetes:超详细k8s-面试题总结

简述 ETCD 及其特点？

etcd 是 CoreOS 团队发动的开源我的项目，是一个治理配置信息和服务发现（service discovery）的我的项目，它的指标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。

• 特点：
• 简略：反对 REST 格调的 HTTP+JSON API
• 平安：反对 HTTPS 形式的拜访
• 疾速：反对并发 1k/s 的写操作
• 牢靠：反对分布式构造，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来实现分布式系统一致性的算法。

简述 ETCD 适应的场景？

etcd 基于其优良的特点，可宽泛的利用于以下场景：

服务发现(Service Discovery)：服务发现次要解决在同一个分布式集群中的过程或服务，要如何能力找到对方并建设连贯。实质上来说，服务发现就是想要理解集群中是否有过程在监听 udp 或 tcp 端口，并且通过名字就能够查找和连贯。

音讯公布与订阅：在分布式系统中，最实用的一种组件间通信形式就是音讯公布与订阅。即构建一个配置共享核心，数据提供者在这个配置核心公布音讯，而音讯使用者则订阅他们关怀的主题，一旦主题有音讯公布，就会实时告诉订阅者。通过这种形式能够做到分布式系统配置的集中式治理与动静更新。利用中用到的一些配置信息放到 etcd 上进行集中管理。

负载平衡：在分布式系统中，为了保障服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即便其中的某一个服务生效了，也不影响应用。etcd 自身分布式架构存储的信息拜访反对负载平衡。etcd 集群化当前，每个 etcd 的外围节点都能够解决用户的申请。所以，把数据量小然而拜访频繁的音讯数据间接存储到 etcd 中也能够实现负载平衡的成果。

分布式告诉与协调：与音讯公布和订阅相似，都用到了 etcd 中的 Watcher 机制，通过注册与异步告诉机制，实现分布式环境下不同零碎之间的告诉与协调，从而对数据变更做到实时处理。

分布式锁：因为 etcd 应用 Raft 算法放弃了数据的强一致性，某次操作存储到集群中的值必然是全局统一的，所以很容易实现分布式锁。锁服务有两种应用形式，一是放弃独占，二是管制时序。

集群监控与 Leader 竞选：通过 etcd 来进行监控实现起来非常简单并且实时性强。

简述什么是 Kubernetes？

Kubernetes 是一个全新的基于容器技术的分布式系统撑持平台。是 Google 开源的容器集群管理系统（谷歌外部:Borg）。在 Docker 技术的根底上，为容器化的利用提供部署运行、资源调度、服务发现和动静伸缩等一系列残缺性能，进步了大规模容器集群治理的便捷性。并且具备齐备的集群治理能力，多层次的平安防护和准入机制、多租户利用撑持能力、通明的服务注册和发现机制、內建智能负载均衡器、弱小的故障发现和自我修复能力、服务滚动降级和在线扩容能力、可扩大的资源主动调度机制以及多粒度的资源配额治理能力。

简述 Kubernetes 和 Docker 的关系？

Docker 提供容器的生命周期治理和，Docker 镜像构建运行时容器。它的次要长处是将将软件 / 利用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移植性等长处。

Kubernetes 用于关联和编排在多个主机上运行的容器。

简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？

Minikube 是一种能够在本地轻松运行一个单节点 Kubernetes 群集的工具。

Kubectl 是一个命令行工具，能够应用该工具管制 Kubernetes 集群管理器，如查看群集资源，创立、删除和更新组件，查看应用程序。

Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。

简述 Kubernetes 常见的部署形式？

常见的 Kubernetes 部署形式有：

• kubeadm：也是举荐的一种部署形式；
• 二进制：CentOS 搭建 K8S，一次性胜利，珍藏了！
• minikube：在本地轻松运行一个单节点 Kubernetes 群集的工具。
• 简略几步，无坑部署最小化 K8S 集群
• Kubernetes 部署如此简略，看齐全明确了

简述 Kubernetes 如何实现集群治理？

在集群治理方面，Kubernetes 将集群中的机器划分为一个 Master 节点和一群工作节点 Node。其中，在 Master 节点运行着集群治理相干的一组过程 kube-apiserver、kube-controller-manager 和 kube-scheduler，这些过程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等治理能力，并且都是全自动实现的。举荐大家看看：轻松治理 Kubernetes 集群的 7 个工具。

简述 Kubernetes 的劣势、适应场景及其特点？

Kubernetes 作为一个齐备的分布式系统撑持平台，其次要劣势：

• 容器编排
• 轻量级
• 开源
• 弹性伸缩
• 负载平衡

Kubernetes 常见场景：

• 疾速部署利用
• 疾速扩大利用
• 无缝对接新的利用性能
• 节俭资源，优化硬件资源的应用

Kubernetes 相干特点：

• 可移植: 反对私有云、公有云、混合云、多重云（multi-cloud）。
• 可扩大: 模块化,、插件化、可挂载、可组合。
• 自动化: 主动部署、主动重启、主动复制、主动伸缩 / 扩大。

简述 Kubernetes 的毛病或以后的不足之处？

Kubernetes 以后存在的毛病（有余）如下：

• 装置过程和配置绝对艰难简单。
• 治理服务绝对繁琐。
• 运行和编译须要很多工夫。
• 它比其余替代品更低廉。
• 对于简略的应用程序来说，可能不须要波及 Kubernetes 即可满足。

简述 Kubernetes 相干根底概念？

master：k8s 集群的治理节点，负责管理集群，提供集群的资源数据拜访入口。领有 Etcd 存储服务（可选），运行 Api Server 过程，Controller Manager 服务过程及 Scheduler 服务过程。

node（worker）：Node（worker）是 Kubernetes 集群架构中运行 Pod 的服务节点，是 Kubernetes 集群操作的单元，用来承载被调配 Pod 的运行，是 Pod 运行的宿主机。运行 docker eninge 服务，守护过程 kunelet 及负载均衡器 kube-proxy。

pod：运行于 Node 节点上，若干相干容器的组合(Kubernetes 之 Pod 实现原理)。Pod 内蕴含的容器运行在同一宿主机上，应用雷同的网络命名空间、IP 地址和端口，可能通过 localhost 进行通信。Pod 是 Kurbernetes 进行创立、调度和治理的最小单位，它提供了比容器更高层次的形象，使得部署和治理更加灵便。一个 Pod 能够蕴含一个容器或者多个相干容器。

label：Kubernetes 中的 Label 本质是一系列的 Key/Value 键值对，其中 key 与 value 可自定义。Label 能够附加到各种资源对象上，如 Node、Pod、Service、RC 等。一个资源对象能够定义任意数量的 Label，同一个 Label 也能够被增加到任意数量的资源对象下来。Kubernetes 通过 Label Selector（标签选择器）查问和筛选资源对象。

Replication Controller：Replication Controller 用来治理 Pod 的正本，保障集群中存在指定数量的 Pod 正本。集群中正本的数量大于指定数量，则会进行指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保障数量不变。Replication Controller 是实现弹性伸缩、动静扩容和滚动降级的外围。

Deployment：Deployment 在外部应用了 RS 来实现目标，Deployment 相当于 RC 的一次降级，其最大的特色为能够随时获知以后 Pod 的部署进度。

HPA（Horizontal Pod Autoscaler）：Pod 的横向主动扩容，也是 Kubernetes 的一种资源，通过追踪剖析 RC 管制的所有 Pod 指标的负载变动状况，来确定是否须要针对性的调整 Pod 正本数量。

Service：Service(Kubernetes 之服务发现)定义了 Pod 的逻辑汇合和拜访该汇合的策略，是实在服务的形象。Service 提供了一个对立的服务拜访入口以及服务代理和发现机制，关联多个雷同 Label 的 Pod，用户不须要理解后盾 Pod 是如何运行。

Volume：Volume 是 Pod 中可能被多个容器拜访的共享目录，Kubernetes 中的 Volume 是定义在 Pod 上，能够被一个或多个 Pod 中的容器挂载到某个目录下。

Namespace：Namespace 用于实现多租户的资源隔离，可将集群外部的资源对象调配到不同的 Namespace 中，造成逻辑上的不同我的项目、小组或用户组，便于不同的 Namespace 在共享应用整个集群的资源的同时还能被别离治理。

简述 Kubernetes 集群相干组件？

Kubernetes Master 管制组件，调度治理整个零碎（集群），蕴含如下组件:

Kubernetes API Server：作为 Kubernetes 零碎的入口，其封装了外围对象的增删改查操作，以 RESTful API 接口方式提供给内部客户和外部组件调用，集群内各个功能模块之间数据交互和通信的核心枢纽。

Kubernetes Scheduler：为新建设的 Pod 进行节点 (node) 抉择(即调配机器)，负责集群的资源调度。

Kubernetes Controller：负责执行各种控制器，目前曾经提供了很多控制器来保障 Kubernetes 的失常运行。

Replication Controller：治理保护 Replication Controller，关联 Replication Controller 和 Pod，保障 Replication Controller 定义的正本数量与理论运行 Pod 数量统一。

Node Controller：治理保护 Node，定期检查 Node 的衰弱状态，标识出 (生效 | 未生效) 的 Node 节点。

Namespace Controller：治理保护 Namespace，定期清理有效的 Namespace，包含 Namesapce 下的 API 对象，比方 Pod、Service 等。

Service Controller：治理保护 Service，提供负载以及服务代理。

EndPoints Controller：治理保护 Endpoints，关联 Service 和 Pod，创立 Endpoints 为 Service 的后端，当 Pod 发生变化时，实时更新 Endpoints。

Service Account Controller：治理保护 Service Account，为每个 Namespace 创立默认的 Service Account，同时为 Service Account 创立 Service Account Secret。

Persistent Volume Controller：治理保护 Persistent Volume 和 Persistent Volume Claim，为新的 Persistent Volume Claim 调配 Persistent Volume 进行绑定，为开释的 Persistent Volume 执行清理回收。

Daemon Set Controller：治理保护 Daemon Set，负责创立 Daemon Pod，保障指定的 Node 上失常的运行 Daemon Pod。

Deployment Controller：治理保护 Deployment，关联 Deployment 和 Replication Controller，保障运行指定数量的 Pod。当 Deployment 更新时，管制实现 Replication Controller 和 Pod 的更新。

Job Controller：治理保护 Job，为 Jod 创立一次性工作 Pod，保障实现 Job 指定实现的工作数目

Pod Autoscaler Controller：实现 Pod 的主动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行 Pod 的伸缩动作。

简述 Kubernetes RC 的机制？

Replication Controller 用来治理 Pod 的正本，保障集群中存在指定数量的 Pod 正本。当定义了 RC 并提交至 Kubernetes 集群中之后，Master 节点上的 Controller Manager 组件获悉，并同时巡检零碎中以后存活的指标 Pod，并确保指标 Pod 实例的数量刚好等于此 RC 的期望值，若存在过多的 Pod 正本在运行，零碎会进行一些 Pod，反之则主动创立一些 Pod。

简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别？Replica Set 和 Replication Controller 相似，都是确保在任何给定工夫运行指定数量的 Pod 正本。不同之处在于 RS 应用基于汇合的选择器，而 Replication Controller 应用基于权限的选择器。

简述 kube-proxy 作用？

kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变动状况，创立路由规定以提供服务 IP 和负载平衡性能。简略了解此过程是 Service 的通明代理兼负载均衡器，其外围性能是将到某个 Service 的拜访申请转发到后端的多个 Pod 实例上。

简述 kube-proxy iptables 原理？

Kubernetes 从 1.2 版本开始，将 iptables 作为 kube-proxy 的默认模式。iptables 模式下的 kube-proxy 不再起到 Proxy 的作用，其外围性能：通过 API Server 的 Watch 接口实时跟踪 Service 与 Endpoint 的变更信息，并更新对应的 iptables 规定，Client 的申请流量则通过 iptables 的 NAT 机制“间接路由”到指标 Pod。

简述 kube-proxy ipvs 原理？

IPVS 在 Kubernetes1.11 中降级为 GA 稳定版。IPVS 则专门用于高性能负载平衡，并应用更高效的数据结构（Hash 表），容许简直有限的规模扩张，因而被 kube-proxy 驳回为最新模式。

在 IPVS 模式下，应用 iptables 的扩大 ipset，而不是间接调用 iptables 来生成规定链。iptables 规定链是一个线性的数据结构，ipset 则引入了带索引的数据结构，因而当规定很多时，也能够很高效地查找和匹配。

能够将 ipset 简略了解为一个 IP（段）的汇合，这个汇合的内容能够是 IP 地址、IP 网段、端口等，iptables 能够间接增加规定对这个“可变的汇合”进行操作，这样做的益处在于能够大大减少 iptables 规定的数量，从而缩小性能损耗。

简述 kube-proxy ipvs 和 iptables 的异同？

iptables 与 IPVS 都是基于 Netfilter 实现的，但因为定位不同，二者有着实质的差异：iptables 是为防火墙而设计的；IPVS 则专门用于高性能负载平衡，并应用更高效的数据结构（Hash 表），容许简直有限的规模扩张。

与 iptables 相比，IPVS 领有以下显著劣势：

• 1、为大型集群提供了更好的可扩展性和性能；
• 2、反对比 iptables 更简单的复制平衡算法（最小负载、起码连贯、加权等）；
• 3、反对服务器健康检查和连贯重试等性能；
• 4、能够动静批改 ipset 的汇合，即便 iptables 的规定正在应用这个汇合。

简述 Kubernetes 中什么是动态 Pod？

动态 pod 是由 kubelet 进行治理的仅存在于特定 Node 的 Pod 上，他们不能通过 API Server 进行治理，无奈与 ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无奈对他们进行健康检查。动态 Pod 总是由 kubelet 进行创立，并且总是在 kubelet 所在的 Node 上运行。

简述 Kubernetes 中 Pod 可能位于的状态？

Pending：API Server 曾经创立该 Pod，且 Pod 内还有一个或多个容器的镜像没有创立，包含正在下载镜像的过程。

Running：Pod 内所有容器均已创立，且至多有一个容器处于运行状态、正在启动状态或正在重启状态。

Succeeded：Pod 内所有容器均胜利执行退出，且不会重启。

Failed：Pod 内所有容器均已退出，但至多有一个容器退出为失败状态。

Unknown：因为某种原因无奈获取该 Pod 状态，可能因为网络通信不畅导致。

简述 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 数据中心。

简述 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 进行健康检查。

简述 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 掉。

简述 Kubernetes Pod 的 LivenessProbe 探针的常见形式？

kubelet 定期执行 LivenessProbe 探针来诊断容器的衰弱状态，通常有以下三种形式：

ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器衰弱。

TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 查看，若能建设 TCP 连贯，则表明容器衰弱。

HTTPGetAction：通过容器的 IP 地址、端口号及门路调用 HTTP Get 办法，若响应的状态码大于等于 200 且小于 400，则表明容器衰弱。

简述 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。

简述 Kubernetes 初始化容器（init container）？

init container 的运行形式与利用容器不同，它们必须先于利用容器执行实现，当设置了多个 init container 时，将按程序一一运行，并且只有前一个 init container 运行胜利后能力运行后一个 init container。当所有 init container 都胜利运行后，Kubernetes 才会初始化 Pod 的各种信息，并开始创立和运行利用容器。

简述 Kubernetes deployment 降级过程？

• 初始创立 Deployment 时，零碎创立了一个 ReplicaSet，并按用户的需要创立了对应数量的 Pod 正本。
• 当更新 Deployment 时，零碎创立了一个新的 ReplicaSet，并将其正本数量扩大到 1，而后将旧 ReplicaSet 缩减为 2。
• 之后，零碎持续依照雷同的更新策略对新旧两个 ReplicaSet 进行一一调整。
• 最初，新的 ReplicaSet 运行了对应个新版本 Pod 正本，旧的 ReplicaSet 正本数量则缩减为 0。

简述 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）来管制滚动更新的过程。

简述 Kubernetes DaemonSet 类型的资源个性？

DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行，并且每个节点只能运行一个 pod，这是它和 deployment 资源对象的最大也是惟一的区别。因而，在定义 yaml 文件中，不反对定义 replicas。

它的个别应用场景如下：

• 在去做每个节点的日志收集工作。
• 监控每个节点的的运行状态。

简述 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 的正本数量，实现扩缩容操作。

简述 Kubernetes Service 类型？

通过创立 Service，能够为一组具备雷同性能的容器利用提供一个对立的入口地址，并且将申请负载散发到后端的各个容器利用上。其次要类型有：

• ClusterIP：虚构的服务 IP 地址，该地址用于 Kubernetes 集群外部的 Pod 拜访，在 Node 上 kube-proxy 通过设置的 iptables 规定进行转发；
• NodePort：应用宿主机的端口，使可能拜访各 Node 的内部客户端通过 Node 的 IP 地址和端口号就能拜访服务；
• LoadBalancer：应用外接负载均衡器实现到服务的负载散发，须要在 spec.status.loadBalancer 字段指定内部负载均衡器的 IP 地址，通常用于私有云。

简述 Kubernetes Service 散发后端的策略？

Service 负载散发的策略有：RoundRobin 和 SessionAffinity

• RoundRobin：默认为轮询模式，即轮询将申请转发到后端的各个 Pod 上。
• SessionAffinity：基于客户端 IP 地址进行会话放弃的模式，即第 1 次将某个客户端发动的申请转发到后端的某个 Pod 上，之后从雷同的客户端发动的申请都将被转发到后端雷同的 Pod 上。

简述 Kubernetes Headless Service？

在某些利用场景中，若须要人为指定负载均衡器，不应用 Service 提供的默认负载平衡的性能，或者应用程序心愿晓得属于同组服务的其余实例。Kubernetes 提供了 Headless Service 来实现这种性能，即不为 Service 设置 ClusterIP（入口 IP 地址），仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。

简述 Kubernetes 内部如何拜访集群内的服务？

对于 Kubernetes，集群外的客户端默认状况，无奈通过 Pod 的 IP 地址或者 Service 的虚构 IP 地址: 虚构端口号进行拜访。通常能够通过以下形式进行拜访 Kubernetes 集群内的服务：

映射 Pod 到物理机：将 Pod 端口号映射到宿主机，即在 Pod 中采纳 hostPort 形式，以使客户端利用可能通过物理机拜访容器利用。

映射 Service 到物理机：将 Service 端口号映射到宿主机，即在 Service 中采纳 nodePort 形式，以使客户端利用可能通过物理机拜访容器利用。

映射 Sercie 到 LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址。这种用法仅用于在私有云服务提供商的云平台上设置 Service 的场景。

简述 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 提供的是对外服务，则实际上实现的是边缘路由器的性能。

简述 Kubernetes 镜像的下载策略？

K8s 的镜像下载策略有三种：Always、Never、IFNotPresent。

• Always：镜像标签为 latest 时，总是从指定的仓库中获取镜像。
• Never：禁止从仓库中下载镜像，也就是说只能应用本地镜像。
• IfNotPresent：仅当本地没有对应镜像时，才从指标仓库中下载。默认的镜像下载策略是：当镜像标签是 latest 时，默认策略是 Always；当镜像标签是自定义时（也就是标签不是 latest），那么默认策略是 IfNotPresent。

简述 Kubernetes 的负载均衡器？

负载均衡器是裸露服务的最常见和规范形式之一。

依据工作环境应用两种类型的负载均衡器，即外部负载均衡器或内部负载均衡器。外部负载均衡器主动均衡负载并应用所需配置调配容器，而内部负载均衡器将流量从内部负载疏导至后端容器。

简述 Kubernetes 各模块如何与 API Server 通信？

Kubernetes API Server 作为集群的外围，负责集群各功能模块之间的通信。集群内的各个功能模块通过 API Server 将信息存入 etcd，当须要获取和操作这些数据时，则通过 API Server 提供的 REST 接口（用 GET、LIST 或 WATCH 办法）来实现，从而实现各模块之间的信息交互。

如 kubelet 过程与 API Server 的交互：每个 Node 上的 kubelet 每隔一个工夫周期，就会调用一次 API Server 的 REST 接口报告本身状态，API Server 在接管到这些信息后，会将节点状态信息更新到 etcd 中。

如 kube-controller-manager 过程与 API Server 的交互：kube-controller-manager 中的 Node Controller 模块通过 API Server 提供的 Watch 接口实时监控 Node 的信息，并做相应解决。

如 kube-scheduler 过程与 API Server 的交互：Scheduler 通过 API Server 的 Watch 接口监听到新建 Pod 正本的信息后，会检索所有合乎该 Pod 要求的 Node 列表，开始执行 Pod 调度逻辑，在调度胜利后将 Pod 绑定到指标节点上。

简述 Kubernetes Scheduler 作用及实现原理？

Kubernetes Scheduler 是负责 Pod 调度的重要功能模块，Kubernetes Scheduler 在整个零碎中承当了“承前启后”的重要性能，“承上”是指它负责接管 Controller Manager 创立的新 Pod，为其调度至指标 Node；“启下”是指调度实现后，指标 Node 上的 kubelet 服务过程接管后继工作，负责 Pod 接下来生命周期。

Kubernetes Scheduler 的作用是将待调度的 Pod（API 新创建的 Pod、Controller Manager 为补足正本而创立的 Pod 等）依照特定的调度算法和调度策略绑定（Binding）到集群中某个适合的 Node 上，并将绑定信息写入 etcd 中。

在整个调度过程中波及三个对象，别离是待调度 Pod 列表、可用 Node 列表，以及调度算法和策略。

Kubernetes Scheduler 通过调度算法调度为待调度 Pod 列表中的每个 Pod 从 Node 列表中抉择一个最适宜的 Node 来实现 Pod 的调度。随后，指标节点上的 kubelet 通过 API Server 监听到 Kubernetes Scheduler 产生的 Pod 绑定事件，而后获取对应的 Pod 清单，下载 Image 镜像并启动容器。

简述 Kubernetes Scheduler 应用哪两种算法将 Pod 绑定到 worker 节点？

Kubernetes Scheduler 依据如下两种调度算法将 Pod 绑定到最合适的工作节点：

预选（Predicates）：输出是所有节点，输入是满足预选条件的节点。kube-scheduler 依据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源有余或者不满足预选策略的条件则无奈通过预选。如“Node 的 label 必须与 Pod 的 Selector 统一”。

优选（Priorities）：输出是预选阶段筛选出的节点，优选会依据优先策略为通过预选的 Nodes 进行打分排名，抉择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具备越高的排名。

简述 Kubernetes kubelet 的作用？

在 Kubernetes 集群中，在每个 Node（又称 Worker）上都会启动一个 kubelet 服务过程。该过程用于解决 Master 下发到本节点的工作，治理 Pod 及 Pod 中的容器。每个 kubelet 过程都会在 API Server 上注册节点本身的信息，定期向 Master 汇报节点资源的应用状况，并通过 cAdvisor 监控容器和节点资源。

简述 Kubernetes kubelet 监控 Worker 节点资源是应用什么组件来实现的？

kubelet 应用 cAdvisor 对 worker 节点资源进行监控。在 Kubernetes 零碎中，cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会主动启动 cAdvisor 服务，而后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。

简述 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 定义网络策略，配合策略控制器（Policy Controller）进行策略的实现。

简述 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 数据长久化的形式有哪些？

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 节点进行扩容，从而将利用零碎进行程度扩大。次要过程如下：

• 1、在该 Node 上装置 Docker、kubelet 和 kube-proxy 服务；
• 2、而后配置 kubelet 和 kubeproxy 的启动参数，将 Master URL 指定为以后 Kubernetes 集群 Master 的地址，最初启动这些服务；
• 3、通过 kubelet 默认的主动注册机制，新的 Worker 将会主动退出现有的 Kubernetes 集群中；
• 4、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，因而在进行关机保护之前，倡议先应用 kubectl drain 将该节点的 Pod 进行驱赶，而后进行关机保护。

简述 Kubernetes 集群联邦？

Kubernetes 集群联邦能够将多个 Kubernetes 集群作为一个集群进行治理。因而，能够在一个数据中心 / 云中创立多个 Kubernetes 集群，并应用集群联邦在一个中央管制 / 治理所有集群。

简述 Helm 及其劣势？

Helm 是 Kubernetes 的软件包管理工具。相似 Ubuntu 中应用的 apt、Centos 中应用的 yum 或者 Python 中的 pip 一样。

Helm 可能将一组 K8S 资源打包对立治理, 是查找、共享和应用为 Kubernetes 构建的软件的最佳形式。

Helm 中通常每个包称为一个 Chart，一个 Chart 是一个目录（个别状况下会将目录进行打包压缩，造成 name-version.tgz 格局的繁多文件，不便传输和存储）。

Helm 劣势

在 Kubernetes 中部署一个能够应用的利用，须要波及到很多的 Kubernetes 资源的独特合作。应用 helm 则具备如下劣势：

• 对立治理、配置和更新这些扩散的 k8s 的利用资源文件；
• 散发和复用一套利用模板；
• 将利用的一系列资源当做一个软件包治理。
• 对于利用发布者而言，能够通过 Helm 打包利用、治理利用依赖关系、治理利用版本并公布利用到软件仓库。
• 对于使用者而言，应用 Helm 后不必须要编写简单的利用部署文件，能够以简略的形式在 Kubernetes 上查找、装置、降级、回滚、卸载应用程序。

起源：https://www.yuque.com/docs/sh…