简述 Kubernetes 的优势、适应场景及其特点？ 答： Kubernetes 作为一个完备的分布式系统支撑平台，其主要优势： l 容器编排 l 轻量级 l 开源 l 弹性伸缩 l 负载均衡 Kubernetes 常见场景： l 快速部署应用 l 快速扩展应用 l 无缝对接新的应用功能 l 节省资源，优化硬件资源的使用 Kubernetes 相关特点： l 可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。 l 可扩展: 模块化,、插件化、可挂载、可组合。 l 自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。
简述 Kubernetes 的缺点或当前的不足之处？ Kubernetes 当前存在的缺点（不足）如下： l 安装过程和配置相对困难复杂。 l 管理服务相对繁琐。 l 运行和编译需要很多时间。 l 它比其他替代品更昂贵。 l 对于简单的应用程序来说，可能不需要涉及 Kubernetes 即可满足。
简述 Kubernetes 相关基础概念？ 答： l master：k8s 集群的管理节点，负责管理集群，提供集群的资源数据访问入口。 拥有 Etcd 存储服务（可选），运行 Api Server 进程，Controller Manager 服务 进程及 Scheduler 服务进程。 l node（worker）：Node（worker）是 Kubernetes 集群架构中运行 Pod 的服 务节点，是 Kubernetes 集群操作的单元，用来承载被分配 Pod 的运行，是 Pod 运行的宿主机。运行 docker eninge 服务，守护进程 kunelet 及负载均衡器 kube-proxy。 l pod：运行于 Node 节点上，若干相关容器的组合。Pod 内包含的容器运行在同 一宿主机上，使用相同的网络命名空间、IP 地址和端口，能够通过 localhost 进 行通信。Pod 是 Kurbernetes 进行创建、调度和管理的最小单位，它提供了比容 器更高层次的抽象，使得部署和管理更加灵活。一个 Pod 可以包含一个容器或者 多个相关容器。 l label：Kubernetes 中的 Label 实质是一系列的 Key/Value 键值对，其中 key 与 value 可自定义。Label 可以附加到各种资源对象上，如 Node、Pod、Service、 RC 等。一个资源对象可以定义任意数量的 Label，同一个 Label 也可以被添加到 任意数量的资源对象上去。Kubernetes 通过 Label Selector（标签选择器）查询 和筛选资源对象。 l Replication Controller：Replication Controller 用来管理 Pod 的副本，保证集 群中存在指定数量的 Pod 副本。集群中副本的数量大于指定数量，则会停止指定 数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量 不变。Replication Controller 是实现弹性伸缩、动态扩容和滚动升级的核心。 l Deployment：Deployment 在内部使用了 RS 来实现目的，Deployment 相当 于 RC 的一次升级，其最大的特色为可以随时获知当前 Pod 的部署进度。 l HPA（Horizontal Pod Autoscaler）：Pod 的横向自动扩容，也是 Kubernetes 的一种资源，通过追踪分析 RC 控制的所有 Pod 目标的负载变化情况，来确定是 否需要针对性的调整 Pod 副本数量。 l Service：Service 定义了 Pod 的逻辑集合和访问该集合的策略，是真实服务的抽 象。Service 提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个 相同 Label 的 Pod，用户不需要了解后台 Pod 是如何运行。 l Volume：Volume 是 Pod 中能够被多个容器访问的共享目录，Kubernetes 中的 Volume 是定义在 Pod 上，可以被一个或多个 Pod 中的容器挂载到某个目录下。 l Namespace：Namespace 用于实现多租户的资源隔离，可将集群内部的资源对 象分配到不同的 Namespace 中，形成逻辑上的不同项目、小组或用户组，便于 不同的 Namespace 在共享使用整个集群的资源的同时还能被分别管理。
简述 Kubernetes 集群相关组件？ 答：Kubernetes Master 控制组件，调度管理整个系统（集群），包含如下组件: l Kubernetes API Server：作为 Kubernetes 系统的入口，其封装了核心对象的增 删改查操作，以 RESTful API 接口方式提供给外部客户和内部组件调用，集群内 各个功能模块之间数据交互和通信的中心枢纽。 l Kubernetes Scheduler：为新建立的 Pod 进行节点(node)选择(即分配机器)，负 责集群的资源调度。 l Kubernetes Controller：负责执行各种控制器，目前已经提供了很多控制器来保 证 Kubernetes 的正常运行。 l Replication Controller：管理维护 Replication Controller，关联 Replication Controller 和 Pod，保证 Replication Controller 定义的副本数量与实际运行 Pod 数量一致。 l Node Controller：管理维护 Node，定期检查 Node 的健康状态，标识出(失效| 未失效)的 Node 节点。 l Namespace Controller：管理维护 Namespace，定期清理无效的 Namespace， 包括 Namesapce 下的 API 对象，比如 Pod、Service 等。 l Service Controller：管理维护 Service，提供负载以及服务代理。 l EndPoints Controller：管理维护 Endpoints，关联 Service 和 Pod，创建 Endpoints 为 Service 的后端，当 Pod 发生变化时，实时更新 Endpoints。 l Service Account Controller：管理维护 Service Account，为每个 Namespace 创建默认的 Service Account，同时为 Service Account 创建 Service Account Secret。 l Persistent Volume Controller：管理维护 Persistent Volume 和 Persistent Volume Claim，为新的 Persistent Volume Claim 分配 Persistent Volume 进 行绑定，为释放的 Persistent Volume 执行清理回收。 l Daemon Set Controller：管理维护 Daemon Set，负责创建 Daemon Pod，保 证指定的 Node 上正常的运行 Daemon Pod。 l Deployment Controller：管理维护 Deployment，关联 Deployment 和 Replication Controller，保证运行指定数量的 Pod。当 Deployment 更新时， 控制实现 Replication Controller 和 Pod 的更新。 l Job Controller：管理维护 Job，为 Jod 创建一次性任务 Pod，保证完成 Job 指 定完成的任务数目 l 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 ipvs 和 iptables 的异同？ 答：iptables 与 IPVS 都是基于 Netfilter 实现的，但因为定位不同，二者有着本质的 差别：iptables 是为防火墙而设计的；IPVS 则专门用于高性能负载均衡，并使用更高 效的数据结构（Hash 表），允许几乎无限的规模扩张。 与 iptables 相比，IPVS 拥有以下明显优势： l 1、为大型集群提供了更好的可扩展性和性能； l 2、支持比 iptables 更复杂的复制均衡算法（最小负载、最少连接、加权等）； l 3、支持服务器健康检查和连接重试等功能； l 4、可以动态修改 ipset 的集合，即使 iptables 的规则正在使用这个集合。
简述 Kubernetes 中什么是静态 Pod？ 答：静态 pod 是由 kubelet 进行管理的仅存在于特定 Node 的 Pod 上，他们不能通 过 API Server 进行管理，无法与 ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检查。静态 Pod 总是由 kubelet 进行创建，并且总是在 kubelet 所在的 Node 上运行。
简述 Kubernetes 中 Pod 可能位于的状态？ 答： l Pending：API Server 已经创建该 Pod，且 Pod 内还有一个或多个容器的镜像没 有创建，包括正在下载镜像的过程。 l Running：Pod 内所有容器均已创建，且至少有一个容器处于运行状态、正在启 动状态或正在重启状态。 l Succeeded：Pod 内所有容器均成功执行退出，且不会重启。 l Failed：Pod 内所有容器均已退出，但至少有一个容器退出为失败状态。 l Unknown：由于某种原因无法获取该 Pod 状态，可能由于网络通信不畅导致。
简述 Kubernetes 创建一个 Pod 的主要流程？ 答：Kubernetes 中创建一个 Pod 涉及多个组件之间联动，主要流程如下： l 1、客户端提交 Pod 的配置信息（可以是 yaml 文件定义的信息）到 kubeapiserver。 l 2、Apiserver 收到指令后，通知给 controller-manager 创建一个资源对象。 l 3、Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据 中心中。 l 4、Kube-scheduler 检测到 pod 信息会开始调度预选，会先过滤掉不符合 Pod 资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行 pod 的节点， 然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。 l 5、Kubelet 根据 scheduler 发来的资源配置单运行 pod，运行成功后，将 pod 的运行信息返回给 scheduler，scheduler 将返回的 pod 运行状况的信息存储到 etcd 数据中心。
简述 Kubernetes 中 Pod 的重启策略？ 答：Pod 重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处 的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败 时，kubelet 将根据 RestartPolicy 的设置来进行相应操作。 Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。 l Always：当容器失效时，由 kubelet 自动重启该容器； l OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器； l Never：不论容器运行状态如何，kubelet 都不会重启该容器。 同时 Pod 的重启策略与控制方式关联，当前可用于管理 Pod 的控制器包括 ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（静态 Pod）。 不同控制器的重启策略限制如下： l RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行； l Job：OnFailure 或 Never，确保容器执行完成后不再重启； l kubelet：在 Pod 失效时重启，不论将 RestartPolicy 设置为何值，也不会对 Pod 进行健康检查。
简述 Kubernetes 中 Pod 的健康检查方式？ 答：对 Pod 的健康检查可以通过两类探针来检查：LivenessProbe 和 ReadinessProbe。 l LivenessProbe 探针：用于判断容器是否存活（running 状态），如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将杀掉该容器，并根据容器 的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针，kubelet 认为 该容器的 LivenessProbe 探针返回值用于是“Success”。 l ReadineeProbe 探针：用于判断容器是否启动完成（ready 状态）。如果 ReadinessProbe 探针探测到失败，则 Pod 的状态将被修改。Endpoint Controller 将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 Eenpoint。 l startupProbe 探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间 启动而被上面两类探针 kill 掉。
简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式？ 答：kubelet 定期执行 LivenessProbe 探针来诊断容器的健康状态，通常有以下三种 方式： l ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器健康。 l TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP 连接，则表明容器健康。 l HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响 应的状态码大于等于 200 且小于 400，则表明容器健康。
简述 Kubernetes Pod 的常见调度方式？ 答：Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式： l Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本， 以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。 l NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以 通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。 l NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前 有两种节点亲和力表达： l requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定 的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。 l preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满 足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。 l Taints 和 Tolerations（污点和容忍）： l Taint：使 Node 拒绝特定 Pod 运行； l Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。
简述 Kubernetes 自动扩容机制？ 答：Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器实现基于 CPU 使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能 指标，并与 HPA 资源对象中的扩缩容条件进行对比，在满足条件时对 Pod 副本数量 进行调整。 l 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，可以为一组具有相同功能的容器应用提供一个统一的入口地址， 并且将请求负载分发到后端的各个容器应用上。其主要类型有： l ClusterIP：虚拟的服务 IP 地址，该地址用于 Kubernetes 集群内部的 Pod 访问， 在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发； l NodePort：使用宿主机的端口，使能够访问各 Node 的外部客户端通过 Node 的 IP 地址和端口号就能访问服务； l LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在 spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址，通常用于公有云。
简述 Kubernetes Service 分发后端的策略？ 答：Service 负载分发的策略有：RoundRobin 和 SessionAffinity l RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个 Pod 上。 l 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 集群内的服务： l 映射 Pod 到物理机：将 Pod 端口号映射到宿主机，即在 Pod 中采用 hostPort 方 式，以使客户端应用能够通过物理机访问容器应用。 l 映射 Service 到物理机：将 Service 端口号映射到宿主机，即在 Service 中采用 nodePort 方式，以使客户端应用能够通过物理机访问容器应用。 l 映射 Sercie 到 LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。
简述 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 绑定到最合适的工作节点： l 预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kubescheduler 根据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源不足或 者不满足预选策略的条件则无法通过预选。如“Node 的 label 必须与 Pod 的 Selector 一致”。 l 优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过 预选的 Nodes 进行打分排名，选择得分最高的 Node。例如，资源越富裕、负载 越小的 Node 可能具有越高的排名。
简述 Kubernetes kubelet 的作用？ 答：在 Kubernetes 集群中，在每个 Node（又称 Worker）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。 每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节 点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。
简述 Kubernetes 如何保证集群的安全性？ 答：Kubernetes 通过一系列机制来实现集群的安全控制，主要有如下不同的维度： l 基础设施方面：保证容器与其所在宿主机的隔离； l 权限方面： ¡ 最小权限原则：合理限制所有组件的权限，确保组件只执行它被授权的行为， 通过限制单个组件的能力来限制它的权限范围。 ¡ 用户权限：划分普通用户和管理员的角色。 l 集群方面： ¡ API Server 的认证授权：Kubernetes 集群中所有资源的访问和变更都是通过 Kubernetes API Server 来实现的，因此需要建议采用更安全的 HTTPS 或 Token 来识别和认证客户端身份（Authentication），以及随后访问权限的 授权（Authorization）环节。 ¡ API Server 的授权管理：通过授权策略来决定一个 API 调用是否合法。对合 法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的 RBAC 方式来提升集群安全授权。 ¡ 敏感数据引入 Secret 机制：对于集群敏感数据建议使用 Secret 方式进行保 护。 ¡ AdmissionControl（准入机制）：对 kubernetes api 的请求过程中，顺序 为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。
简述 Kubernetes 准入机制？ 答：在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入 控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的 error 信息。 准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对 象进行操作。常用组件（控制代码）如下： l AlwaysAdmit：允许所有请求 l AlwaysDeny：禁止所有请求，多用于测试环境。 l ServiceAccount：它将 serviceAccounts 实现了自动化，它会辅助 serviceAccount 做一些事情，比如如果 pod 没有 serviceAccount 属性，它会自 动添加一个 default，并确保 pod 的 serviceAccount 始终存在。 l LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件 定义在 namespace 中 LimitRange 对象中。 l NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的 namespace，则这个请求被拒绝。
简述 Kubernetes RBAC 及其特点（优势）？ 答：RBAC 是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网 络资源的访问的方法。 相对于其他授权模式，RBAC 具有如下优势： l 对集群中的资源和非资源权限均有完整的覆盖。 l 整个 RBAC 完全由几个 API 对象完成， 同其他 API 对象一样， 可以用 kubectl 或 API 进行操作。 l 可以在运行时进行调整，无须重新启动 API Server。
简述 Kubernetes Secret 有哪些使用方式？ 答：创建完 secret 之后，可通过如下三种方式使用： l 在创建 Pod 时，通过为 Pod 指定 Service Account 来自动使用该 Secret。 l 通过挂载该 Secret 到 Pod 来使用它。 l 在 Docker 镜像下载时使用，通过指定 Pod 的 spc.ImagePullSecrets 来引用它。
简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略？ 答： 在 PodSecurityPolicy 对象中可以设置不同字段来控制 Pod 运行时的各种安全策略， 常见的有： l 特权模式：privileged 是否允许 Pod 以特权模式运行。 l 宿主机资源：控制 Pod 对宿主机资源的控制，如 hostPID：是否允许 Pod 共享宿 主机的进程空间。 l 用户和组：设置运行容器的用户 ID（范围）或组（范围）。 l 提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限， 通常在设置非 root 用户（MustRunAsNonRoot）时进行设置。 l 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 模型中只涉及两个概念：容器和网络。 l 容器（Container）：是拥有独立 Linux 网络命名空间的环境，例如使用 Docker 或 rkt 创建的容器。容器需要拥有自己的 Linux 网络命名空间，这是加入网络的必 要条件。 l 网络（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 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 的最大容量值。