K8S常见知识点整理

大道之简

已于 2024-06-11 10:03:44 修改

阅读量66

点赞数

分类专栏：云原生文章标签： kubernetes 容器云原生

于 2024-06-04 23:03:08 首次发布

原文链接：https://mp.weixin.qq.com/s/2hBAWIESF297MjzBBp1Jpg

版权

云原生专栏收录该内容

5 篇文章 1 订阅

订阅专栏

转自大数据于云原生技术分享公众号

1、什么是K8S

Kubernetes（简称 k8s）是一个开源的容器编排平台，用于自动部署、扩展和管理容器化应用程序。它最初由 Google 设计并捐赠给 Cloud Native Computing Foundation（CNCF）来维护。

Kubernetes 提供了一个用于部署和管理微服务架构的系统，它支持多种容器运行时，如 Docker、containerd 等。

Kubernetes 的主要特点包括：

1、可移植性：Kubernetes 可以在公有云、私有云、混合云以及多云环境中运行。

2、可扩展性：Kubernetes 设计为模块化和插件化，可以根据需要添加或移除功能。

3、自动化：Kubernetes 能够自动部署应用程序、重启失败的容器、复制容器、根据负载自动扩展或缩减容器数量。

4、声明式配置：Kubernetes 使用声明式配置，用户通过定义期望的最终状态，Kubernetes 会自动将系统的实际状态转变为期望状态。

Kubernetes 的架构主要由以下几个核心组件组成：

Master 节点：控制平面组件，包括 API 服务器、调度器、控制器管理器和 etcd（用于存储所有集群数据）。
Node 节点：工作负载节点，运行应用程序容器。每个 Node 节点包含 kubelet（与 Master 通信并管理容器）、kube-proxy（网络代理）以及容器运行时（如 Docker）。
Pod：Kubernetes 的基本工作单元，每个 Pod 包含一个或多个容器。
Service：定义一组 Pod 的访问规则和负载均衡，提供稳定的网络接口。
Volume：提供数据持久化存储，可以被 Pod 中的容器挂载。
Namespace：提供隔离的环境，每个 Namespace 下可以运行一组资源。
ReplicaSet/Deployment：管理 Pod 的副本数量，确保指定数量的 Pod 始终运行。
StatefulSet：用于管理有状态的分布式应用。
DaemonSet：确保所有（或某些）节点上运行 Pod 的副本。
Job：用于执行一次性任务。

Kubernetes 通过这些组件提供了一套完整的工具，用于自动化部署、扩展、管理和运行容器化应用程序。

它已经成为云原生技术栈中不可或缺的一部分，被广泛应用于现代的微服务架构和持续集成/持续部署（CI/CD）流程中。

2、K8S主要组件

控制平面组件（master）：

kube-apiserver：集群的前端，负责处理对 Kubernetes API 的请求。它是 Kubernetes 集群的通信中心。

etcd：一个分布式键值存储，用于存储集群的所有配置数据，是 Kubernetes 所有集群数据的中心数据库。

kube-scheduler：负责决定新创建的 Pods 应该调度到哪个节点上。

kube-controller-manager：运行控制器进程，这些进程负责维护集群的状态，例如复制控制器、节点控制器、端点控制器等。

cloud-controller-manager（如果运行在云平台上）：云控制器管理器是与特定云提供商的接口，包含节点控制器、路由控制器等云特定控制器。

节点组件（node）：

kubelet：在每个节点上运行的主要节点代理，负责与容器运行时通信，维持容器的生命周期，并向 API 服务器报告节点上容器的状态。

container-runtime：容器运行时负责运行容器，例如 Docker、containerd 或 CRI-O。

kube-proxy：网络代理，负责在节点上实现 Pod 网络规则，确保 Pod 可以接收网络流量。

Pods：Kubernetes 的最小部署单元，每个 Pod 包含一个或多个容器。

附加组件（通常作为集群的一部分运行）：

CoreDNS：提供 DNS 服务，用于服务发现。

Ingress 控制器：管理外部访问到集群内服务的 HTTP(S) 路由。

Dashboard：提供基于 Web 的用户界面，用于管理和监控 Kubernetes 集群。

这些组件共同工作，提供了一个强大的平台，使得容器化应用程序的部署、扩展和管理变得简单而高效。

控制平面组件负责整个集群的管理，而节点组件则负责在各个节点上运行应用程序和服务。

3、有状态和无状态

无状态应用（Stateless Applications）：无状态应用是指那些不依赖于任何特定实例状态的应用程序。这意味着无论何时何地启动应用实例，它们都能以相同的方式运行，并且不依赖于之前的执行状态。

无状态应用通常易于扩展，因为它们可以被随意地复制和销毁，而不会丢失数据或状态。

无状态应用的特点：

1、可替换性：实例之间没有区别，任何一个实例都可以被另一个完全相同的实例替换。

2、可扩展性：可以根据负载轻松地增加或减少实例的数量。

3、独立性：每个实例都是独立的，不依赖于其他实例的状态。4、无持久性存储：不依赖于本地存储，所有数据都存储在外部存储系统中。

有状态应用（Stateful Applications）：有状态应用则是指那些需要维护和跟踪状态的应用程序。这些状态可能包括用户会话信息、应用配置、数据库记录等。有状态应用通常需要持久化存储，并且可能需要特定的网络标识符和稳定的 IP 地址。

有状态应用的特点：

1、状态持久性：应用需要在多个周期内保持状态信息。

2、顺序性：实例的创建和删除通常是有序的，不能随意替换。

3、唯一性：每个实例通常有唯一的标识，如数据库的主节点或从节点。4、持久化存储：需要持久化存储卷来保存状态信息。

5、Kubernetes 中的无状态和有状态应用的管理

在 Kubernetes 中，无状态应用通常通过 Deployment 和 ReplicaSet 来管理，这些资源确保了应用的副本数量始终符合期望的状态。

而有状态应用则通过 StatefulSet 来管理，StatefulSet 会跟踪每个 Pod 的状态，并确保它们有序地部署和删除，同时提供稳定的存储和网络标识符。

4、Deployment 控制器

Kubernetes 的 Deployment 控制器是一个高级抽象，用于声明式地管理无状态应用的副本，Deployment 控制器通过使用 ReplicaSet 来实现这一点，ReplicaSet 确保指定数量的 Pod 副本始终处于运行状态。

Deployment 控制器的主要功能：

声明式更新：Deployment 允许你声明应用的新版本，而控制器会自动进行滚动更新，逐步替换旧版本的 Pod，直到所有 Pod 都更新到新版本。

回滚：如果新版本的应用出现问题，Deployment 控制器允许你回滚到之前的版本。

扩缩容：你可以修改 Deployment 中的副本数量，以扩容或缩容应用，控制器会相应地增加或减少 Pod 的数量。

暂停和恢复：在更新过程中，如果需要，你可以暂停 Deployment 的更新，然后在适当的时候恢复。

健康检查：Deployment 控制器会监控 Pod 的健康，如果 Pod 失败，它会根据需要重启 Pod 或创建新的 Pod。

Deployment 资源通常通过 YAML 或 JSON 文件定义，这些文件描述了应用的期望状态，包括容器镜像、资源限制、环境变量等。

然后，你可以使用 kubectl 命令行工具来创建、更新或回滚 Deployment。

deployment的滚动更新策略，

rollingUpdate 策略，主要有两个参数，maxUnavailable、 maxSurge。 maxUnavailable：最大不可用数，maxUnavailable用于指定deployment在更新的过程中不可用状态的pod的最大数量，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如25%，计算时向下取整。

maxSurge：最大激增数，maxSurge指定deployment在更新的过程中pod的总数量最大能超过 pod副本数多少个，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如 25%，计算时向上取整。

4、StatefulSet 控制器

Kubernetes 的 StatefulSet 控制器是专门用于管理有状态应用的资源对象。

与 Deployment 控制器不同，StatefulSet 被设计用来处理那些需要持久化存储和唯一网络标识符的应用，例如数据库或其他需要保持状态的服务。

StatefulSet 控制器的特点：

有序部署和删除：StatefulSet 中的 Pod 会按照顺序创建和删除。每个 Pod 都有一个唯一的、持久的网络标识符（通常是 Pod 的名称），这使得它们可以被用作长期服务。

稳定的持久化存储：StatefulSet 确保每个 Pod 都能够挂载一个持久化存储卷，这个存储卷的生命周期独立于 Pod，即使 Pod 被删除或重新创建，存储卷也会保持不变。

唯一性和顺序性：StatefulSet 中的每个 Pod 都有一个唯一的标识（通常是 Pod 名称），并且它们会按照顺序启动和停止。这对于需要严格顺序或唯一性的场景（如分布式数据库的复制集群）非常重要。

更新和回滚：StatefulSet 支持滚动更新，但与 Deployment 不同，更新是逐个 Pod 进行的，而不是整个集群同时更新。此外，StatefulSet 也支持回滚到之前的版本。

头部服务：StatefulSet 可以与头部服务（Headless Service）结合使用，头部服务不会分配一个负载均衡器的虚拟 IP，而是直接暴露 Pod 的 IP 地址，这对于需要直接与 Pod 通信的客户端来说非常有用。

StatefulSet 通常通过 YAML 或 JSON 文件定义，这些文件描述了有状态应用的期望状态，包括 Pod 模板、更新策略、持久化存储卷等。

然后，你可以使用 kubectl 命令行工具来创建、更新或删除 StatefulSet。

5、DaemonSet

Kubernetes 的 DaemonSet 控制器是一种确保所有（或者某些）节点上都运行指定 Pod 副本的机制。

DaemonSet 被设计用来在集群中的每个节点上运行 Pod 的副本，或者根据节点的标签选择器来运行 Pod 的副本。这通常用于运行集群级别的服务，如日志收集、监控代理、网络插件等。

DaemonSet 控制器的特点：

节点选择：DaemonSet 可以配置为在集群中的所有节点上运行，或者仅在具有特定标签的节点上运行。

自动维护：当新节点加入集群时，DaemonSet 控制器会自动在这些节点上创建 Pod 副本。同样，当节点被删除时，相关的 Pod 也会被清理。

版本管理：DaemonSet 允许你更新 Pod 模板以升级或修复运行在节点上的软件。控制器会逐个节点地更新 Pod，确保服务的平滑过渡。

故障恢复：如果 Pod 失败或节点不可用，DaemonSet 控制器会尝试在该节点上重新创建 Pod。

资源管理：DaemonSet 允许你为 Pod 设置资源请求和限制，确保即使在资源受限的节点上也能有效地运行。

DaemonSet 的使用场景：

日志收集：在每个节点上运行日志收集器，如 Fluentd 或 Logstash，以便收集和聚合容器日志。

监控代理：部署像 Prometheus Node Exporter 这样的监控代理，以收集节点级别的指标。

网络功能虚拟化：运行网络相关的 Pod，如负载均衡器、VPN 终端节点等。

系统组件：在每个节点上运行系统级别的服务，如 DNS 缓存、时间同步服务等。

通过 DaemonSet 控制器，Kubernetes 能够确保关键的集群级服务在所有（或选定的）节点上稳定运行，从而支持集群的基础设施和服务的连续性和可靠性。

DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是和deployment资源对象的最大也是唯一的区别。所以，在其yaml文件中，不支持定义replicas，除此之外，与Deployment、RS等资源对象的写法相同,DaemonSet一般使用的场景有：

在去做每个节点的日志收集工作；

监控每个节点的的运行状态;

6、如何水平扩展Pod

在 Kubernetes 中，水平扩展 Pod 通常是通过修改 Deployment 或 StatefulSet 资源的副本数量来实现的。

这种操作称为“水平扩展”（Horizontal Scaling），与“垂直扩展”（Vertical Scaling）相对，后者涉及改变单个 Pod 的资源规格（如 CPU 或内存）。

以下是水平扩展 Pod 的步骤：

使用 Deployment 进行水平扩展：

获取当前 Deployment 状态：显示 Deployment 的当前配置，包括副本数量。

编辑 Deployment 以更改副本数量：使用文本编辑器打开 Deployment 的 YAML 文件，或者直接使用 kubectl edit 命令，在 spec.replicas 字段中，更改你希望的副本数量。

保存并退出编辑器：如果你使用的是 kubectl edit，直接保存并退出编辑器即可。Kubernetes 会自动应用更改。

验证更改：检查输出中的 READY 和 UP-TO-DATE 副本数量，确保它们匹配你设置的新副本数量。

使用 StatefulSet 进行水平扩展：

对于 StatefulSet，水平扩展通常用于有状态应用，因为每个 Pod 都需要保持其状态的一致性。扩展 StatefulSet 可能需要额外的步骤来确保数据的一致性和 Pod 的唯一性。

编辑 StatefulSet 以更改副本数量：与 Deployment 类似，你可以编辑 StatefulSet 的 YAML 文件或使用 kubectl edit 命令。

修改 spec.replicas 字段的值。

考虑状态迁移：对于有状态的应用，扩展 StatefulSet 可能需要考虑数据迁移和重新平衡。确保你的应用支持水平扩展，并且你已经准备好处理任何必要的数据迁移。

验证更改：使用 kubectl get statefulset 命令来验证 StatefulSet 的新副本数量。

7、pod 动态弹性扩缩容 HPA

在 Kubernetes 中，Horizontal Pod Autoscaler (HPA) 是一种自动缩放 Pod 数量的机制，它根据 CPU 使用率或其他指标来增加或减少 Pod 的副本数。

HPA 使得应用程序能够根据实际工作负载动态调整资源，从而提高效率和性能。

HPA 的工作原理：

HPA 通过观察 Pod 的 CPU 使用率或其他自定义指标，并根据这些指标的当前值来调整 Pod 的副本数量。

当指标超过或低于预设的阈值时，HPA 会自动增加或减少 Pod 的数量。

如何设置 HPA：

创建或更新 Deployment：确保你有一个 Deployment 或 StatefulSet 来管理你的 Pod。如果还没有，你需要先创建一个。

定义 HPA 资源：使用 kubectl 命令或创建一个 HPA 的 YAML 文件来定义 HPA 规则。你需要指定以下信息：

要自动缩放的 Deployment 或 StatefulSet 的名称。

要监控的指标（默认是 CPU）。

目标指标的阈值（例如，CPU 的 50%）。

最小副本数和最大副本数。

应用 HPA 配置：使用 kubectl 应用 HPA 配置

监控 HPA 状态：使用 kubectl 命令查看 HPA 的状态和事件

通过使用 HPA，你可以确保 Kubernetes 集群中的应用程序能够根据实际需求自动调整资源，从而实现高效的负载管理和成本优化。

8、pod 中健康检查的三种探测方式？

k8s 中每种探测机制都支持三种健康检查方法，分别是命令行exec，httpGet和tcpSocket，其中exec通用性最强，适用与大部分场景，tcpSocket适用于TCP业务，httpGet适用于web业务。

1、exec（自定义健康检查）：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。

2、httpGet：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。

3、tcpSocket：通过容器的 IP 地址和端口号执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康。

探针探测结果有以下值：

1、Success：表示通过检测。

2、Failure：表示未通过检测。

3、Unknown：表示检测没有正常进行。

健康检查常用的可选参数：

1、initialDelaySeconds：探测延迟时长，容器启动后多久开始进行第一次探测工作，默认0秒。

2、periodSeconds：探测频度，频率过高会对pod带来较大的额外开销，频率过低则无法及时反映容器产生的错误，默认10秒。

3、timeoutSeconds：探测的超时时长，默认1秒。

4、failureThreshold：处于成功状态时，探测连续失败几次可被认为失败，默认3秒。

4、successThreshold：处于失败状态时，探测连续成功几次，被认为成功，默认1秒。

9、健康检查 liveness ，readiness，startup探针？

1、存活探针（Liveness Probes）：

存活探针用于检查容器是否仍然健康运行。

如果存活探针失败，Kubernetes 会根据 Pod 规范中定义的 restartPolicy 重启容器。

存活探针可以是 HTTP GET 请求、TCP 端口检查或执行命令。

Liveness 探针 restartPolicy有三个可选值：

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

2、就绪探针（Readiness Probes）：

就绪探针用于检查容器是否准备好接收流量。

如果就绪探针失败，Kubernetes 会将 Pod 标记为非就绪，并且服务（Service）不会将流量路由到该 Pod。

就绪探针通常在容器启动后不久执行，以确保所有必要的初始化操作已经完成。

3、启动探针（Startup Probes）：

启动探针是 Kubernetes 1.16 版本引入的，用于在容器启动时执行的健康检查。

启动探针允许你定义一个自定义的检查，以确保容器在开始接受流量之前已经完全初始化。

如果启动探针失败，Kubernetes 会重启容器，直到探针成功为止。

这些探针提供了一种机制，让 Kubernetes 能够自动检测和响应容器的健康状态，确保应用程序的稳定性和可靠性。

10、如何进行持久化存储？

在 Kubernetes (k8s) 中进行持久化存储主要涉及以下几个组件和概念：

PersistentVolume (PV)

1、PV 是集群中的一块存储，由管理员配置或使用存储类动态配置。

2、PV 独立于使用它的任何单个 Pod，具有自己的生命周期。

3、PV 描述了存储的细节，比如 NFS、iSCSI 或云提供商特定的存储系统。

PersistentVolumeClaim (PVC)

1、PVC 是用户对存储的请求，类似于 Pod 耗用节点资源的方式，PVC 申领会耗用 PV 资源。

2、PVC 可以请求特定的大小和访问模式，例如 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany。

3、PVC 必须与某个符合条件的 PV 进行绑定后才能被 Pod 使用。

PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”； PVC则是用户对存储资源的一个“申请”；

StorageClass

1、StorageClass 是创建 PV 的模板，定义了 PV 的属性和创建 PV 所需使用的存储插件。

2、当用户创建了一个 PVC 后，Kubernetes 会根据 PVC 中的 StorageClassName 找到对应的 StorageClass，并创建所需的 PV。

动态供应 (Dynamic Provisioning)

1、动态供应允许 Kubernetes 根据 PVC 的需求自动创建 PV。

2、这是通过 StorageClass 和 PersistentVolumeController 实现的，它会监控未绑定的 PVC 并尝试将它们与合适的 PV 绑定。

访问模式 (Access Modes)

1、PV 支持三种访问模式：ReadWriteOnce、ReadOnlyMany 和 ReadWriteMany。

2、ReadWriteOnce 允许单个节点以读写方式挂载卷。

3、ReadOnlyMany 允许多个节点以只读方式挂载卷。

4、ReadWriteMany 允许多个节点以读写方式挂载卷。

回收策略 (Reclaim Policies)

1、PV 的回收策略定义了当 PVC 被删除后，PV 应该如何处理。

2、有三种回收策略：Retain、Recycle 和 Delete。

3、Retain 保留 PV 和其数据，需要手动回收。

4、Recycle 回收 PV，清空数据，使其可供再利用。

5、Delete 删除 PV 和其数据，以及从外部基础设施中移除相关存储资产。

使用 PVC 作为存储

1、用户创建 PVC 来请求存储资源。

2、PVC 被绑定到合适的 PV 上。

3、Pod 通过引用 PVC 来使用持久化存储。

存储卷的调度

1、Kubernetes 的调度器会考虑存储卷的需求，将 Pod 调度到合适的节点上。

2、可以通过存储卷的标签和节点的选择器来影响调度决策。

存储插件 (Volume Plugins)

1、Kubernetes 使用存储插件来实现与不同存储系统的集成。

2、插件负责实现 PV 和 PVC 的具体操作，如挂载、卸载和格式化。

pv的访问模式有哪几种：

pv的访问模式有3种，如下：

ReadWriteOnce，简写：RWO 表示，只仅允许单个节点以读写方式挂载；

ReadOnlyMany，简写：ROX 表示，可以被许多节点以只读方式挂载；

ReadWriteMany，简写：RWX 表示，可以被多个节点以读写方式挂载；

pv的回收策略有哪几种：

主要有3中回收策略：retain 保留、delete 删除、 Recycle回收。

Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。

Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。

Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。（这种策略已经被废弃，不用记）

在pv的生命周期中，一般有几种状态：

Available，表示pv已经创建正常，处于可用状态；

Bound，表示pv已经被某个pvc绑定，注意，一个pv一旦被某个pvc绑定，那么该pvc就独占该pv，其他 pvc不能再与该pv绑定；

Released，表示pvc被删除了，pv状态就会变成已释放；

Failed，表示pv的自动回收失败；

pv存储空间不足怎么扩容?

一般的，我们会使用动态分配存储资源，在创建storageclass时指定参数 allowVolumeExpansion：true，表示允许用户通过修改pvc申请的存储空间自动完成pv的扩容，当增大pvc的存储空间时，不会重新创建一个pv，而是扩容其绑定的后端pv。这样就能完成扩容了。但是allowVolumeExpansion这个特性只支持扩容空间不支持减少空间。

本地存储卷 local volume

Kubernetes（k8s）中的本地存储卷（local volume）是一种使用节点上的物理存储资源的存储方式。

这种存储卷类型允许用户通过标准的持久卷声明（PersistentVolumeClaim, PVC）接口以简单且可移植的方式访问节点的本地存储。

本地存储卷主要用于那些对性能有较高要求，且能够容忍共享磁盘的应用场景，例如分布式文件系统或数据库系统。

1、这是一个很新的存储类型，建议在k8s v1.10+以上的版本中使用。目前这种类型是企业里用的最多的一种方式了，结合存储类（StorageClass ）一起使用。

2、Local volume 允许用户通过标准PVC接口以简单且可移植的方式访问node节点的本地存储。PV的定义中需要包含描述节点亲和性的信息，k8s系统则使用该信息将容器调度到正确的node节点。

3、Local volume 就是用来解决 hostPath volume 面临的 portability, disk accounting, and scheduling 的缺陷。PV Controller 和 Scheduler 会对 local PV 做特殊的逻辑处理，以实现 Pod 使用本地存储时发生Pod re-schedule 的情况下能再次调度到 local volume 所在的 Node。

使用场景：

1、使用local-volume插件时，要求使用到了存储设备名或路径都相对固定，不会随着系统重启或增加、减少磁盘而发生变化。

2、静态provisioner配置程序仅支持发现和管理挂载点（对于Filesystem模式存储卷）或符号链接（对于块设备模式存储卷）。对于基于本地目录的存储卷，必须将它们通过bind-mounted的方式绑定到发现目录中。

在 Kubernetes (k8s) 中，hostPath 卷是一种特殊类型的存储卷，它将宿主机上的文件或目录挂载到 Pod 中的容器文件系统中。使用 hostPath 卷时，Pod 可以直接访问宿主机的文件系统。

hostPath 卷的特点包括：

1、性能：由于 hostPath 卷直接使用宿主机的文件系统，因此访问速度通常较快。

2、共享性：Pod 中的所有容器都可以读写 hostPath 卷，这使得它适合用作共享存储。

3、持久性：hostPath 卷的数据持久存在于宿主机上，即使 Pod 被删除，数据也不会丢失。

4、安全性：hostPath 卷可能会带来安全风险，因为它允许 Pod 访问宿主机的文件系统。因此，在使用时需要谨慎，并确保适当的权限和安全措施。

hostPath 卷适用于以下场景：

1、当你需要在 Pod 和宿主机之间共享数据时。

2、当你需要使用宿主机上的特定资源，如设备文件或特殊文件系统时。

3、当你需要持久化存储，但不想使用 Kubernetes 的 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 机制时。

需要注意的是，hostPath 卷可能会影响集群的可移植性，因为 Pod 依赖于宿主机的文件系统。

此外，过度使用 hostPath 卷可能会使集群管理变得复杂，并可能导致资源冲突。在生产环境中，推荐使用 PersistentVolume 和 PersistentVolumeClaim 来管理持久化存储。

在 Kubernetes（k8s）中，emptyDir 卷是一种临时存储卷，它在 Pod 调度到节点上时被创建，并且在 Pod 从节点上删除时被销毁。

emptyDir 卷通常用于存储临时数据，如缓存和工作文件，这些数据在 Pod 重新启动时会丢失。

emptyDir 卷的特点包括：

1、临时性：emptyDir 卷是临时的，它的生命周期与 Pod 相同。当 Pod 被删除时，卷中的数据也会被清除。

2、共享性：Pod 中的所有容器都可以读写 emptyDir 卷，这使得它适合用作共享存储。

3、性能：由于数据存储在节点的本地存储上，emptyDir 卷通常具有较高的性能。

4、数据持久性：emptyDir 卷不提供持久化存储，所有数据在 Pod 终止时都会丢失。

emptyDir 卷适用于以下场景：

1、作为应用程序的临时工作空间。

2、存储需要在容器之间共享的临时数据。

3、用作应用程序的缓存层。

需要注意的是，emptyDir 卷的数据存储在节点的本地存储上，这意味着如果节点发生故障，数据可能会丢失。

对于需要持久化的数据，应该使用 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）机制。

此外，emptyDir 卷的大小可能受到节点上可用存储空间的限制。

11、如何进行持久化存储？

在 Kubernetes (k8s) 中，滚动更新是一种更新应用程序的方式，它会逐个更新 Pod，以确保服务的可用性和稳定性。

滚动更新通常与 Deployment 资源一起使用，Deployment 会自动创建和管理 ReplicaSet，而 ReplicaSet 负责管理 Pod 的副本。

以下是执行滚动更新的基本步骤：

1、更新应用程序镜像：首先，你需要更新应用程序的容器镜像。这可以通过修改 Deployment 资源的 YAML 文件来完成，指定新的镜像标签。

2、应用更新：使用 kubectl 命令应用更新后的配置文件。

3、监控更新过程：你可以使用 kubectl 命令来监控更新的状态。

4、回滚：如果在滚动更新过程中出现问题，你可以使用 kubectl rollout undo 命令来回滚到之前的版本。

5、确认更新：一旦更新完成并且 Pod 稳定运行，你可以使用 kubectl get pods 命令来确认所有 Pod 都已成功更新到新的镜像版本。

滚动更新的关键在于，它会逐步替换旧的 Pod 实例，同时保持应用程序的高可用性。Kubernetes 会确保在任何时候都有足够的 Pod 副本来处理用户请求，即使在更新过程中也是如此。

此外，Kubernetes 还支持自动滚动更新，你可以在 Deployment 配置中设置滚动更新策略，如最大不可用 Pod 数量和更新暂停时间等。这些设置可以帮助你更好地控制滚动更新的行为，以适应不同的应用场景和需求。

12、污点、容忍、亲和性

在Kubernetes中，污点（Taints）、容忍度（Tolerations）和亲和性是调度Pod到节点的关键机制。

以下是对这些概念的详细解释：

1、污点（Taints）：污点是一种标记，可以应用于节点上，用来限制哪些Pod可以被调度到该节点。如果一个节点被设置了某个污点，而一个Pod没有相应的容忍度来匹配这个污点，那么这个Pod就不会被调度到该节点上。

2、容忍度（Tolerations）：容忍度是Pod上的一个属性，允许Pod在调度时忽略节点上的某些污点。这意味着如果一个Pod具有与节点上的污点相匹配的容忍度，它将能够被调度到该节点上。

3、亲和性（Affinity）：亲和性是指Pod倾向于被调度到具有特定属性的节点上的规则。例如，可以设置Pod倾向于被调度到具有特定标签或运行特定Pod的节点上。这种机制有助于实现负载均衡、服务隔离等高级调度策略。

4、反亲和性（Anti-Affinity）：反亲和性是与亲和性相反的规则，它确保Pod不会被调度到具有特定属性的节点上。这通常用于避免将敏感或不兼容的应用部署在同一物理位置。

13、什么是Ingress

Ingress 是 Kubernetes 中的一个资源对象，它管理外部用户访问集群内服务的 HTTP 和 HTTPS 路由。

Ingress 可以提供负载均衡、SSL 终端和基于名称的虚拟托管。简而言之，Ingress 允许你通过定义规则集来控制如何将外部请求路由到集群内的不同服务。

Ingress 的关键特性：

1、路由规则：Ingress 允许你定义基于 URL 路径、主机名或其他 HTTP 头部信息的路由规则，从而将流量导向不同的后端服务。

2、负载均衡：Ingress 控制器通常会实现负载均衡机制，将进入的流量分配到后端的多个 Pod 上。

3、SSL/TLS 终端：Ingress 可以管理 SSL/TLS 证书，为通过它路由的流量提供加密。

4、虚拟托管：基于名称的虚拟托管允许你通过一个单一的 IP 地址来托管多个域名。

注解：Ingress 资源可以包含注解，这些注解可以被 Ingress 控制器用来扩展或自定义行为。

Ingress 的工作原理：

1、Ingress 资源：你创建一个 Ingress 资源，并定义一组规则，这些规则指定了哪些外部请求应该被路由到集群中的哪些服务。

2、Ingress 控制器：Ingress 控制器是一个 Pod 或一组 Pod，它运行在你的 Kubernetes 集群中，并监听 Ingress 资源的变化。当 Ingress 规则更新时，Ingress 控制器会相应地更新其内部的负载均衡器配置。

3、流量路由：当外部请求到达集群时，Ingress 控制器会根据 Ingress 规则将请求路由到正确的服务。

Ingress 是 Kubernetes 中实现外部访问管理的重要机制，Ingress 控制器的选择和配置对于实现期望的路由行为至关重要。

常见的 Ingress 控制器包括 NGINX Ingress Controller、Traefik 和 HAProxy。

14、什么是Service

在 Kubernetes (k8s) 中，Service 是一个抽象层，它定义了一种访问 Pod 集合的方式。

Service 允许你通过统一的接口访问一组执行相同功能的 Pod，无论这些 Pod 如何变化、扩展或缩减。

Service 通过负载均衡器将网络流量分发到后端的 Pod 集合，并且提供了服务发现和负载分发的功能。

Service 的主要特点：

负载均衡：Service 可以在多个 Pod 之间分配网络流量，提供负载均衡功能。

服务发现：Service 提供了一个稳定的 DNS 名称，Pod 可以通过该名称发现和通信，而不需要知道后端 Pod 的具体 IP 地址。

抽象：Service 抽象了 Pod 的集合，即使 Pod 的 IP 地址发生变化，客户端也不需要重新配置，因为它们总是通过 Service 访问服务。

持久性：Service 是持久的，即使 Pod 被删除或重新创建，Service 仍然保持不变。

支持多种访问模式：Service 支持多种访问模式，如 ClusterIP、NodePort、LoadBalancer 和 ExternalName。

Service 类型：ClusterIP：默认的 Service 类型，它在集群内部提供一个虚拟 IP 地址，用于服务发现和负载均衡。

NodePort：在集群的所有节点上打开一个端口，将外部流量转发到 Service 的 ClusterIP。

LoadBalancer：为 Service 分配一个外部负载均衡器，自动配置云提供商的负载均衡服务。

ExternalName：允许将 Service 定义为对外部服务的引用，例如，将 Service 指向一个外部数据库的 DNS 名称。

15、limit 和 request 含义和区别？

在 Kubernetes 中，资源限制（limits）和资源请求（requests）是资源管理的两个关键概念，它们用于控制 Pod 如何使用节点上的计算资源（如 CPU 和内存）。

这两个参数在 Pod 的定义中设置，并由 Kubernetes 调度器和节点的 kubelet 组件使用。

Request（请求）

资源请求（requests）表示容器需要的最小资源量。Kubernetes 调度器在为 Pod 选择节点时会考虑这个值，确保节点有足够的资源来满足 Pod 的请求。

如果一个节点没有足够的资源来满足 Pod 的请求，那么该 Pod 将不会被调度到该节点上。

资源请求是 Pod 可以保证获得的最小资源量。即使在资源竞争的情况下，节点也会保证 Pod 能够使用到请求的资源量，但这不意味着 Pod 只能使用这么多资源。

Limit（限制）

资源限制（limits）表示容器可以使用的最大资源量。如果容器尝试超过了这个限制，它可能会被系统终止。设置资源限制可以防止单个容器占用过多资源，从而影响节点上其他容器或 Pod 的运行。

如果一个 Pod 的容器超过了请求的资源量但不超过设置的限制，它仍然可以继续运行，但可能会受到限制，直到资源使用量下降到限制范围内。

区别：

1、保证性：资源请求可以保证 Pod 获得声明的资源量，而资源限制则是 Pod 可以使用资源的上限。

2、调度：请求是调度决策的一部分，确保 Pod 被调度到有足够的资源的节点。限制则用于在 Pod 运行时控制其资源使用，防止过度使用资源。

3、资源竞争：在资源紧张的情况下，满足请求但不能满足限制的 Pod 可能会被杀掉，以保护节点的稳定运行。

16、普通日志和events日志区别？

在 Kubernetes (k8s) 中，普通日志和 Events 日志是两种不同类型的日志，它们记录了集群中发生的不同事件和状态变化。

普通日志（Application Logs）：普通日志通常指的是容器内部应用程序产生的日志。这些日志反映了应用程序的运行情况和状态，对于调试应用程序和监控其性能至关重要。

在 Kubernetes 中，容器的标准输出（stdout）和标准错误（stderr）被重定向并作为日志存储。这些日志可以通过 kubectl logs 命令来访问。

特点：

1、记录应用程序的运行信息和错误。

2、通常输出到容器的 stdout 和 stderr。

3、可以通过 kubectl logs 命令查看。

4、可能需要日志代理（如 Fluentd、Logstash、Filebeat）来收集和转发到中央日志存储系统。

Events 日志：Events 日志是 Kubernetes 系统生成的，记录了集群内发生的特定事件，如 Pod 的调度、创建、删除等。这些事件提供了对 Kubernetes 系统内部操作的洞察，有助于理解集群的状态和行为。

特点：

1、记录 Kubernetes 系统级别的事件。

2、可以通过 kubectl get events 或 kubectl describe 命令查看。

3、提供集群操作和状态变化的历史记录。

4、可以用于事后分析和故障排查。

4、某些工具如 kubernetes-event-exporter 可以将这些事件导出到第三方平台或数据库，以便进行进一步的分析和警报。

在 Kubernetes 集群的运维中，普通日志和 Events 日志都是重要的信息来源。普通日志更多地关注应用程序层面的运行情况，而 Events 日志则关注系统层面的事件和状态变化。

17、etcd 的作用？

在 Kubernetes (k8s) 中，etcd 是一个关键的后端服务，它提供了一个高可用的键值存储系统，用于持久化存储集群的配置数据和状态信息。

etcd 是 CoreOS 团队的项目，它被设计为一个高度可靠的分布式存储系统，适合用作配置共享和服务发现。

etcd 在 Kubernetes 集群中的作用主要包括以下几点：

1、存储配置数据：Kubernetes 集群的所有配置信息，包括 API 对象（如 Pod、Service、ConfigMap、Secret 等）的状态和配置，都存储在 etcd 中。这些数据是集群运行的基础，确保了集群状态的一致性和持久性。

2、支持集群状态同步：etcd 提供了强一致性的分布式存储，这意味着集群中的任何更改都会同步到所有节点上的 etcd 实例。这样，无论从哪个节点访问 Kubernetes API，都能获取到最新的集群状态。

3、实现集群的高可用性：Kubernetes 集群的高可用性部分依赖于 etcd 的高可用性。etcd 集群可以通过多副本部署来实现故障转移和数据恢复，从而确保即使在部分节点故障的情况下，集群的配置数据仍然可用。

4、支持 Leader 选举：在 Kubernetes 集群中，etcd 还用于进行 Leader 选举。例如，kube-apiserver 会使用 etcd 进行 Leader 选举，以确保在任何时候只有一个 kube-apiserver 实例能够处理写入操作，从而避免数据不一致的问题。

5、提供服务发现：etcd 可以用作服务注册和发现的后端存储，允许客户端通过 API 访问集群中的服务信息。这在微服务架构中尤为重要，因为它允许服务之间的动态发现和通信。

6、版本控制和审计：etcd 提供了每个更改的历史记录，这使得 Kubernetes 集群的配置和状态更改可以被审计和回滚。这对于维护集群的安全性和可追溯性至关重要。

etcd 在 Kubernetes 集群中扮演着核心的角色，它不仅存储了集群的配置和状态信息，还支持集群的高可用性和一致性，是 Kubernetes 能够正常运行和扩展的关键组件。

18、什么是 Headless Services？与常规 Services 的区别？

Headless Services 是 Kubernetes 中的一种服务类型，它不维护一个虚拟 IP（VIP）来代理和负载均衡到后端的 Pod。

与常规（非 Headless）Services 相比，Headless Services 不提供负载均衡和单一的访问入口点，而是直接将服务请求转发到后端的 Pod。

常规 Services 与 Headless Services 的主要区别在于：

1、负载均衡和单一入口点：

常规 Services：Kubernetes 为服务分配一个 VIP，所有进入该 VIP 的流量都会根据后端 Pod 的标签选择器进行负载均衡。这意味着，对于常规 Services，外部客户端可以通过一个统一的 IP 地址访问所有后端服务。

Headless Services：不分配 VIP，而是直接暴露后端 Pod 的 IP 地址。外部客户端需要直接与后端 Pod 通信，或者使用其他服务发现机制来确定后端服务的位置。

2、DNS 解析：

常规 Services：当进行 DNS 查询时，Kubernetes 会返回服务的 VIP。

Headless Services：DNS 查询会返回后端 Pod 的 IP 地址列表。客户端可以从中选择一个 Pod 进行通信。

3、应用场景：

常规 Services：适用于需要单一访问入口和负载均衡的场景，如 Web 服务器或其他需要高可用性和流量分发的应用。

Headless Services：适用于需要直接与后端 Pod 通信的场景，如数据库集群的访问、服务发现或当 Pod 需要直接暴露给外部网络时。

Headless Services 提供了一种更灵活的服务暴露方式，允许客户端直接与后端 Pod 通信，而不是通过负载均衡的 VIP。

这在某些特定的应用场景中非常有用，特别是在需要避免额外的网络跳跃或需要直接服务发现的分布式系统中。

19、什么是 ConfigMap 和 Secret？

在 Kubernetes 中，ConfigMap 和 Secret 是两种用于存储和管理配置数据和敏感信息的资源对象，它们使得配置信息和敏感数据（如密码、OAuth 令牌、SSH 密钥等）与应用程序代码分离，从而提高安全性和灵活性。

ConfigMap：

ConfigMap 用于存储非敏感的配置数据，如环境变量、配置文件或命令行参数。ConfigMap 中的数据可以被 Pod 以多种方式使用，例如作为环境变量、命令行参数或在容器内的文件。

ConfigMap 的用途：

1、环境变量：可以将 ConfigMap 中的数据作为环境变量传递给容器。

2、配置文件：可以将配置数据挂载到容器的文件系统中，作为配置文件使用。

3、命令行参数：可以使用 ConfigMap 中的数据作为启动容器时的命令行参数。

Secret

Secret 用于存储敏感信息，如密码、密钥等。与 ConfigMap 类似，Secret 中的数据也可以被 Pod 以多种方式使用，但 Secret 会额外进行加密处理，以确保敏感数据的安全。

Secret 的用途：

1、环境变量：可以将 Secret 中的数据作为环境变量传递给容器。

2、文件：可以将 Secret 中的数据挂载到容器的文件系统中，作为敏感文件使用。

3、TLS 证书：Secret 可以用来存储 TLS 证书和密钥，用于配置服务的 SSL/TLS。

ConfigMap 和 Secret 是 Kubernetes 中管理配置和敏感数据的重要资源对象。

它们使得配置信息和敏感数据与应用程序代码分离，便于管理和更新。

通过使用 ConfigMap 和 Secret，你可以提高应用程序的安全性和可维护性。在实际使用中，应根据数据的敏感性选择合适的资源对象，对于敏感信息应始终使用 Secret。

20、什么是 k8s DNS（CoreDNS）？

Kubernetes (k8s) 使用 CoreDNS 作为其集群内的 DNS 服务，它负责处理集群内的 DNS 查询请求，提供服务发现和负载均衡等功能。

CoreDNS 是 Kubernetes 1.11 版本之后默认的 DNS 解决方案，它取代了之前的 kube-dns。

CoreDNS 概述CoreDNS 是一个开源的 DNS 服务器，它是用 Go 语言编写的，具有高性能和易于扩展的特点。CoreDNS 通过插件系统提供各种功能，可以轻松地通过配置文件来定制 DNS 行为。

CoreDNS 的工作方式

1、服务发现：在 Kubernetes 集群中，服务（Service）是通过 DNS 名称来访问的。当一个 Pod 需要访问另一个服务时，它会向 CoreDNS 发起一个 DNS 查询请求。

2、查询处理：CoreDNS 接收到查询请求后，会根据查询的服务名称和命名空间，通过 Kubernetes API 查询相应的 Service 和 Endpoint 对象。

3、响应构造：一旦找到匹配的 Service 和 Pod，CoreDNS 会构造一个 DNS 响应，包含服务的 ClusterIP 或 Pod 的 IP 地址，并将其发送回请求者。

4、负载均衡：CoreDNS 支持负载均衡功能，可以将流量均匀地分配到后端的多个 Pod 上。

CoreDNS 的配置CoreDNS 的配置文件是 Corefile，它使用类似于 DNS 区域文件的格式。Corefile 中定义了各种插件，这些插件负责处理不同类型的 DNS 查询。例如：

1、kubernetes 插件用于从 Kubernetes API 读取服务和 Pod 信息。

2、prometheus 插件允许 Prometheus 收集 CoreDNS 的性能指标。

3、forward 插件用于将查询转发到上游 DNS 服务器。

4、cache 插件提供了缓存机制，减少对外部 DNS 服务器的查询次数。

CoreDNS 的插件系统CoreDNS 的插件系统非常灵活，允许开发者根据需要添加新的功能。一些常见的插件包括：

1、loadbalance：提供基于 DNS 的负载均衡。

2、cache：提供前端缓存功能。

3、health：对 Endpoint 进行健康检查。

4、etcd：从 etcd 读取 zone 数据。

5、file：从文件中读取 zone 数据。

Pod 的 DNS 策略Kubernetes 支持多种 Pod DNS 策略：

1、Default：继承 Pod 所在宿主机的 DNS 设置。

2、ClusterFirst：优先使用 Kubernetes 环境的 DNS 服务，无法解析的域名转发到宿主机的 DNS 服务器。

3、ClusterFirstWithHostNet：与 ClusterFirst 相同，但适用于 hostNetwork 模式运行的 Pod。

4、None：忽略 Kubernetes 环境的 DNS 配置，通过 spec.dnsConfig 自定义 DNS 配置。

CoreDNS 是 Kubernetes 集群 DNS 功能的核心组件，它通过插件系统提供了灵活的配置和扩展能力。

了解 CoreDNS 的工作原理和配置方法对于有效地管理 Kubernetes 集群内的服务发现和网络流量至关重要。通过监控和日志分析，可以确保 CoreDNS 的正常工作并优化其性能。

21、什么是 Pod？

Pod 是 Kubernetes 中的最小部署单元，它是一组一个或多个容器的集合，这些容器共享存储、网络和运行配置，它们在一个 Pod 中紧密协作。

Pod 作为容器的封装，提供了一种在 Kubernetes 集群中运行和调度应用程序的方式。

Pod 的特点：

1、共享网络：Pod 内的容器共享同一个网络命名空间，这意味着它们可以通过 localhost 互相通信，并且它们都暴露到同一个 IP 地址上。

2、共享存储：Pod 内的容器可以访问相同的存储卷，这允许它们共享数据。如果一个应用程序需要多个服务来处理不同的任务，这些服务可以放在同一个 Pod 中，并通过共享存储来交换信息。

3、独立调度：尽管 Pod 中的容器共享网络和存储，但 Kubernetes 会独立调度每个容器，确保它们可以独立运行和扩展。

4、紧密协作：Pod 中的容器设计用来紧密协作，它们可以是同一个应用程序的不同组件，或者是一个应用程序的不同实例。

5、生命周期：Pod 有其自己的生命周期，它会被创建、启动、运行，最终可能会因为失败、删除或更新而被终止。

6、临时性：Pod 被视为临时的，它们可能会因为节点故障、Pod 失败或集群重新平衡而消失。因此，Pod 不应该存储任何持久化数据，除非使用了持久化存储卷。

1、每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod 都拥有自己的IP地址、主机名、进程等；

2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）； 2、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；

3、一个pod中的容器共享network命名空间；

4、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个 pod来说就不可能存在端口冲突；

5、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；

6、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器。

Pod 的用途：

1、运行应用程序：Pod 可以用来运行单个应用程序或服务。

2、服务部署：Pod 可以包含多个容器，每个容器代表应用程序的不同部分，如 web 服务器和辅助服务。

3、任务执行：Pod 可以用来执行一次性任务，如数据处理或批处理作业。

Pod 在 Kubernetes 中的使用非常灵活，它是集群中实现应用程序部署和管理的基础。

通过使用 Pod，开发者可以将关注点从单个容器转移到整个应用程序的部署和管理，从而简化了容器化应用程序的生命周期管理。

Pod的生命周期：

pod生命周期有的5种状态（也称5种相位），如下：

Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；

Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；

Succeed（成功）：Pod内所有容器均已退出，且不会再重启；

Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态

Unknown（未知）：某于某种原因apiserver无法获取该pod的状态，可能由于网络通行问题导致；

pod一致处于pending状态一般有哪些情况，怎么排查？

一个pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。如果等了一会发现pod一直处于pending状态，那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：

1、调度器调度失败。 Scheduer调度器无法为pod分配一个合适的node节点。而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和性而没有节点满足这些亲和性或反亲和性；以上是调度器调度失败的几种情况。

2、pvc、pv无法动态创建。如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建 redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况 pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。

pod的共享资源？

1）PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；

2）网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；

3）IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；

4）UTS 命名空间：Pod 中的多个容器共享一个主机名；

5）Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes；

22、k8s 中 port、NodePort、targetPort、containerPort 的区别

在 Kubernetes (k8s) 中，port、NodePort、targetPort 和 containerPort 是与网络和服务暴露相关的术语，它们在定义 Kubernetes Service 对象时扮演不同的角色。

以下是这些术语的区别和用途：

port

1、定义：port 是 Service 定义中的一部分，它指定了 Service 对外暴露的端口号。这是集群内部和外部客户端用来访问 Service 的网络端口。

2、用途：当你创建一个 Service 时，你需要定义一个或多个 port，这样集群内的其他组件就可以通过这些端口与 Service 通信。

NodePort

1、定义：NodePort 是一种 Service 类型，它在集群的所有节点上打开一个静态端口（通常在 30000-32767 范围内），并将外部流量转发到 Service 的 port。

2、用途：NodePort 允许外部流量访问集群内部的服务，即使集群运行在私有网络中。外部客户端可以通过任何节点的 IP 地址和 NodePort 来访问 Service。

targetPort

1、定义：targetPort 是 Service 定义中的一个可选字段，它指定了 Service 应该转发到的 Pod 的端口。如果未指定，targetPort 默认为 containerPort。

2、用途：当你的 Pod 监听多个端口或需要 Service 转发到特定的端口时，targetPort 是必需的。它允许你精确控制 Service 流量的目的地。

containerPort

1、定义：containerPort 是 Pod 定义中的一个字段，它指定了容器内部监听的端口号。这是容器应用程序用来接收网络流量的端口。

2、用途：当你创建一个 Pod 并希望它能够接收网络请求时，你需要在 Pod 的定义中指定 containerPort。Service 通过 targetPort 或默认的 containerPort 将流量转发到这些端口。

通过这种方式，port、NodePort、targetPort 和 containerPort 在 Kubernetes 中共同工作，以确保服务的可访问性和网络流量的正确路由。

23、Kubernetes镜像的下载策略?

1）Always：镜像标签为latest时，总是从指定的仓库中获取镜像；

2）Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；

3）IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载；默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是 IfNotPresent；

24、image的状态有那些？

1）Running：Pod所需的容器已经被成功调度到某个节点，且已经成功运行；

2）Pending：APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程；

3）Unknown：APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致；

25、k8s 创建一个pod的详细流程，涉及的组件怎么通信的？

1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；

2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；

3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；

4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；

5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；

1、客户端提交创建请求，可以通过API Server的Restful API，也可以使用如何命令行工具。支持的数据类型包括JSON和YAML。

2、API Server处理用户请求，存储Pod数据到etcd。

3、调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。

4、过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。

5、主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。

6、选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。

7、kubelet根据调度结果执行Pod创建操作：绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。

26、简单描述一下pod的终止过程

1、用户向apiserver发送删除pod对象的命令；

2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；

3、将pod标记为terminating状态；

4、kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；

5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint 列表中删除；

6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；

7、pod对象中的容器进程收到停止信息；

8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；

9、kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。

27、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到 worker节点?

1）预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选；

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

28、简述Kubernetes kubelet的作用?

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

29、简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的?

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

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

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

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

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

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

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