Kubernetes知识汇总

一、Kubernetes（K8s）基本概念

1. 集群（Cluster）
   • 是 Kubernetes 的基本运行环境，由一组节点（Node）组成。这些节点包括至少一个主节点（Master Node）和多个工作节点（Worker Node）。主节点主要负责管理和调度整个集群的资源，如调度容器运行、监控节点状态等；工作节点则是实际运行容器的地方。例如，一个小型的 Web 应用集群可能有一个主节点用于管理，三个工作节点来运行不同服务的容器，像 Web 服务器容器、数据库容器等。
2. Pod
   • 是 Kubernetes 中最小的可部署和可管理的计算单元。一个 Pod 可以包含一个或多个紧密相关的容器，这些容器共享网络和存储资源。例如，一个简单的 Web 应用 Pod 可能包含一个运行 Web 服务器的容器和一个用于收集日志的辅助容器。Pod 中的容器可以通过localhost相互通信，它们的生命周期是紧密耦合的。当 Pod 被创建、删除或重启时，其中的所有容器都会一起进行相应的操作。
3. 容器（Container）
   • 是一种轻量级的、独立运行的软件包，包含了运行一个软件所需的所有内容，如代码、运行时环境、系统工具、库等。在 Kubernetes 中，容器是实际运行应用程序的载体。像常见的 Docker 容器就被广泛应用于 K8s 中。例如，一个运行着 Python Flask 应用的容器，它里面封装了 Python 解释器、Flask 库以及应用的代码，能够独立地提供 Web 服务。
4. Service
   • 是一种抽象，用于定义一组 Pod 的访问策略。它提供了一个稳定的 IP 地址和端口，使得客户端可以通过这个统一的端点访问后端的 Pod。例如，对于一个有多个副本的 Web 服务 Pod，Service 可以将客户端的请求均匀地分发到这些副本上，实现负载均衡。而且，即使 Pod 的 IP 地址因为重启等原因发生变化，Service 仍然可以保证客户端能够正确地访问到服务。

二、Kubernetes 核心组件

1. etcd
   • 是一个分布式的键 - 值存储系统，用于存储 Kubernetes 集群的所有配置数据和状态信息。它是整个集群的 “大脑”，所有组件都依赖它来获取和更新信息。例如，当创建一个新的 Pod 时，相关的配置信息（如 Pod 的名称、所属的命名空间、容器的镜像等）都会被存储到 etcd 中。etcd 通过 Raft 一致性算法来保证数据的一致性和可靠性，确保在多个节点同时访问和修改数据时不会出现数据冲突等问题。
2. kube - apiserver
   • 是 Kubernetes 集群的前端 API 接口，它提供了 HTTP RESTful API，用于接收和处理来自客户端（如 kubectl 命令行工具、Dashboard 等）的请求。例如，当用户通过 kubectl 命令创建一个新的资源（如 Deployment）时，请求会首先发送到 kube - apiserver，它会验证请求的合法性，然后将请求转发到相应的控制器进行处理。它还负责认证、授权和访问控制，确保只有合法的用户和操作才能对集群资源进行访问和修改。
3. kube - controller - manager
   • 是一组控制器的集合，包括节点控制器、副本控制器、端点控制器等。这些控制器负责监控集群的状态，并根据预设的规则和策略进行调整。例如，副本控制器（ReplicationController）会确保指定的 Pod 副本数量始终保持在设定的水平。如果因为某些原因（如节点故障、容器异常退出）导致 Pod 副本数量减少，副本控制器会自动创建新的 Pod 来补充；反之，如果副本数量过多，它会删除多余的 Pod。
4. kube - scheduler
   • 负责将未调度的 Pod 分配到合适的工作节点上。它会考虑多种因素，如节点的资源可用性（CPU、内存等）、节点的负载情况、Pod 的资源需求以及亲和性 / 反亲和性规则等。例如，一个对 CPU 资源需求较高的计算密集型 Pod 可能会被调度到 CPU 资源较为充裕的节点上；如果有一个 Pod 需要和另一个特定的 Pod 运行在同一节点上（基于亲和性规则），kube - scheduler 会按照这个要求进行调度。

三、Kubernetes 资源管理

1. 资源请求（Resource Requests）和资源限制（Resource Limits）
   • 资源请求是指 Pod 在运行时对 CPU 和内存等资源的基本需求。例如，一个 Pod 可能请求 0.5 个 CPU 核心和 1GB 的内存来保证其基本的运行。资源限制则是为了防止 Pod 过度占用资源而设置的上限。比如，限制一个 Pod 最多使用 1 个 CPU 核心和 2GB 的内存。通过合理设置资源请求和限制，可以更好地分配集群资源，避免某个 Pod 过度占用资源而影响其他 Pod 的正常运行。
2. 命名空间（Namespace）
   • 用于在一个集群中划分不同的逻辑区域。它类似于操作系统中的文件夹，可以将不同的资源（如 Pod、Service 等）划分到不同的命名空间中。例如，在一个公司的集群中，可以有一个 “development” 命名空间用于开发环境的资源，一个 “production” 命名空间用于生产环境的资源。这样可以方便地对不同环境的资源进行管理和隔离，不同命名空间中的资源名称可以相同，不会产生冲突

四、Kubernetes 部署方式

1. Deployment
   • 是一种用于管理 Pod 副本的高级资源。它可以方便地创建、更新和回滚应用程序。例如，当要部署一个新的 Web 应用时，可以创建一个 Deployment，指定应用的镜像、副本数量等参数。Deployment 会自动创建指定数量的 Pod 副本。当需要更新应用（如更新镜像版本）时，Deployment 可以通过滚动更新的方式，逐步替换旧的 Pod 副本，以确保应用的不间断服务。如果更新过程中出现问题，还可以快速回滚到之前的版本。
2. DaemonSet
   • 用于确保在每个工作节点上都运行一个特定的 Pod 副本。例如，在一个集群中，可能需要在每个节点上运行一个日志收集的 Pod，这时就可以使用 DaemonSet。它会自动在每个节点上创建和管理 Pod，并且当有新的节点加入集群时，会自动在新节点上创建相应的 Pod；当节点被删除时，也会自动删除该节点上的 Pod。
3. StatefulSet
   • 用于管理有状态应用的部署。与 Deployment 不同，StatefulSet 会为每个 Pod 分配一个稳定的、唯一的标识符。例如，对于一个分布式数据库应用，每个节点都有自己独立的存储和状态，StatefulSet 可以确保每个节点的身份和状态在重启、升级等操作中保持稳定，使得有状态应用能够在 Kubernetes 环境中正确地运行。