[TOC]

1、简介

简介：Kubernetes 也称为 K8s，是用于自动部署、扩缩和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。Kubernetes 源自Google 15 年生产环境的运维经验，同时凝聚了社区的最佳创意和实践。

容器是打包和运行应用程序的好方式。在生产环境中， 你需要管理运行着应用程序的容器，并确保服务不会下线。 例如，如果一个容器发生故障，则你需要启动另一个容器。 如果此行为交由给系统处理，是不是会更容易一些？

这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。

Kubernetes 为你提供：

  • 服务发现和负载均衡

    Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

  • 存储编排

    Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

  • 自动部署和回滚

    你可以使用 Kubernetes 描述已部署容器的所需状态， 它可以以受控的速率将实际状态更改为期望状态。 例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

  • 自动完成装箱计算

    你为 Kubernetes 提供许多节点组成的集群，在这个集群上运行容器化的任务。 你告诉 Kubernetes 每个容器需要多少 CPU 和内存 (RAM)。 Kubernetes 可以将这些容器按实际情况调度到你的节点上，以最佳方式利用你的资源。

  • 自我修复

    Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， 并且在准备好服务之前不将其通告给客户端。

  • 密钥与配置管理

    Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥

    Kubernetes 不是什么

  • 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。

  • 不部署源代码，也不构建你的应用程序。 持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。

  • 不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制 （例如开放服务代理）来访问。

  • 不是日志记录、监视或警报的解决方案。 它集成了一些功能作为概念证明，并提供了收集和导出指标的机制。

  • 不提供也不要求配置用的语言、系统，它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。

  • 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。

  • 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 而 Kubernetes 包含了一组独立可组合的控制过程，可以连续地将当前状态驱动到所提供的预期状态。 你不需要在乎如何从 A 移动到 C，也不需要集中控制，这使得系统更易于使用 且功能更强大、系统更健壮，更为弹性和可扩展。

架构图：

image-20240614190826602

2、组件介绍

当你部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为 节点， 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会托管 Pod ，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pod。 在生产环境中，控制平面通常跨多台计算机运行， 一个集群通常运行多个节点，提供容错性和高可用性。

2.1 kube-apiserver

​ Kubernetes API Server的核心功能是提供Kubernetes各类资源对象的增、删、改、查及Watch等HTTP REST接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还是集群管理的 API入口，是资源配额控制的入口，提供了完备的集群安全机制。

​ API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

2.2 etcd

​ 一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。如果你的 Kubernetes 集群使用 etcd 作为其后台数据库， 请确保你针对这些数据有一份 备份计划。

2.3 kube-scheduler

​ kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。它监听 kube-apiserver，查询还未分配Node的Pod，然后根据调度策略为这些 Pod 分配节点

image-20240912192836645

2.4 kube-controller-manager

​ 在Kubernetes集群中，每个Controller都是这样的一 个“操作系统”，它们通过API Server提供的（List-Watch）接口实时监控集群中特定资源的状态变化，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。当发生各种故障导致某资源对象的状态变化时，Controller会尝试将其状态调整为期望的状态。比如当某个Node 意外宕机时，Node Controller会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态下。Controller Manager是 Kubernetes中各种操作系统的管理者，是集群内部的管理控制中心，也是Kubernetes自动化功能的核心。

​ Controller Manager内部包含Replication Controller、 Node Controller、ResourceQuota Controller、Namespace Controller、 ServiceAccount Controller、Token Controller、Service Controller、 Endpoint Controller、Deployment Controller、Router Controller、Volume Controller等各种资源对象的控制器，每种Controller都负责一种特定资源的控制流程，而Controller Manager正是这些Controller的核心管理者。

​ kube-controller-manager 是控制平面的组件， 负责运行控制器进程。

从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

  • 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
  • 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
  • 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
  • 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

2.5 kubelet

​ kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

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

2.6 kube-proxy

​ kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

​ 在集群中的Service和Pod大量增加以后，每个Node节点上 iptables中的规则会急速膨胀，导致网络性能显著下降，在某些极端情况下甚至会出现规则丢失的情况，并且这种故障难以重现与排查。于是 Kubernetes从1.8版本开始引入第三代的IPVS（IP Virtual Server）模式.

iptables与IPVS虽然都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙设计的；IPVS专门用于高性能负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张，因此被kube-proxy采纳为第三代模式。

与iptables相比，IPVS拥有以下明显优势：

  • 为大型集群提供了更好的可扩展性和性能；
  • 支持比iptables更复杂的复制均衡算法（最小负载、最少连接、 加权等）；
  • 支持服务器健康检查和连接重试等功能；
  • 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
  • 由于IPVS无法提供包过滤、airpin-masquerade tricks（地址伪装）、 SNAT等功能，因此在某些场景（如NodePort的实现）下还要与iptables搭配使用。

2.7 容器运行时（Container Runtime）

​ 容器运行环境是负责运行容器的软件。Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

2.8 CoreDNS

​ CoreDNS 是一种灵活的，可扩展的 DNS 服务器，可以安装为集群内的Pod提供 DNS 服务。用于Kubernetes集群内部Service的解析，可以让Pod把Service名称解析成Service的IP，然后通过service的IP地址进行连接到对应的应用上。同时扮演着服务发现和DNS 解析的重要角色，使得集群中的服务和Pod可以通过 DNS 名称进行通信，而无需手动管理 IP 地址。CoreDNS 的插件化架构、轻量级以及与 Kubernetes 的深度集成，使其成为云原生环境下的理想 DNS 解决方案。

2.9 Calico

​ 为每个 Pod 分配一个唯一的 IP 地址，并确保 Pod 能够跨节点通信。每个 Kubernetes 节点上都会运行一个 calico-node 容器，该容器包含 Calico 的核心代理（Felix）和 BGP 客户端，负责管理和维护路由信息。Calico 将每个节点的路由信息分发到集群中的其他节点，从而实现不同节点上的 Pod 之间的直接通信。

​

​