一文读懂Kubernetes之 K8s 概述

kube-controller-manager组件负责运行控制器进程。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都在同一个进程中运行。控制器有不同的类型，例如：

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

5、cloud-controller-manager(可选的)

cloud-controller-manager组件允许将你的Kubernetes集群连接到云提供商的API，并将与该云平台交互的组件和你的Kubernetes集群交互的组件分离开来。如果你的Kubernetes集群仅仅运行在独立的环境中，则不需要部署cloud-controller-manager组件。

(二)、节点组件

运行节点组件的节点，可称为工作负载节点。节点组件会在每个工作负载节点上运行，负责维护运行的Pod并提供Kubernetes运行时环境。

1、kubelet

kubelet组件在Kubernetes集群的每个工作负载节点上运行，负责维护容器(containers)的生命周期，保证容器(containers)都运行在Pod中。

kubelet组件是基于PodSpec来工作的。每个PodSpec是一个描述Pod的YAML或JSON对象。 kubelet组件接收一组通过各种机制(主要是通过apiserver)提供给它的PodSpec，并确保这些PodSpec中描述的容器处于健康运行状态。kubelet组件只管理由 Kubernetes集群所创建的容器。

2、kube-proxy(可选的)

        kube-proxy组件是Kubernetes集群每个工作负载节点上所运行的网络代理，是实现Kubernetes中服务(Service)概念的一部分。

        kube-proxy组件维护工作负载节点上的一些网络规则，这些网络规则会允许集群内部或者外部的网络会话与Pod进行网络通信。如果操作系统提供了可用的数据包过滤层，则kube-proxy组件会通过它来实现网络规则。否则，kube-proxy组件仅做流量转发。

        如果使用网络插件为服务(Service)实现自身的数据包转发，并提供与kube-proxy组件等效的功能，则不需要在Kubernetes集群的工作负载节点上运行kube-proxy组件。

3、容器运行时(Container runtime)

容器运行时组件在Kubernetes集群的每个工作负载节点上运行。这个基础组件，使得Kubernetes能够有效运行容器，它负责管理Kubernetes集群环境中容器的执行和生命周期。Kubernetes支持许多容器运行时环境，例如containerd、Docker Engine、CRI-O以及Kubernetes CRI(容器运行环境接口)的其他任何实现。

(三)、插件(Addons)

Kubernetes中，插件并非是必须的组件。安装插件能够丰富集群的功能，可以根据实际需求选择插件。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于kube-system命名空间。

1、DNS

Kubernetes集群都应该有集群DNS，因为很多示例都需要DNS服务。集群DNS是一个DNS服务器，与环境中的其他DNS服务器一起工作，它为Kubernetes服务提供 DNS 记录。

2、Web界面(Dashboard)

Dashboard是Kubernetes集群通用的、基于Web的用户界面。它使用户可以通过图形化界面管理集群中运行的应用服务以及集群本身，进行应用部署、故障排除等操作。

3、容器资源监控

容器资源监控将容器常见的时序度量值保存到一个集中的数据库中，并提供浏览这些数据的界面，从而了解应用程序资源使用情况等详细信息。

4、集群层面日志

集群层面日志机制负责将容器的日志数据保存到统一的日志存储系统中，这个日志存储系统提供搜索和浏览日志数据的接口，以便于分析容器崩溃、Pod被逐出或者节点宕机等情况。

5、网络插件

网络插件是实现容器网络接口（CNI）规范的软件组件。它们负责为Pod分配IP地址，并使这些Pod能在集群内部相互通信。

二、Kubernetes核心资源对象

在Kubernetes中，所有的内容都抽象为资源对象。用户管理Kubernetes的过程，即是用户操作资源对象的过程。Kubernetes中核心资源对象详见下文。

(一)、Namespace

Namespace主要是用来进行资源隔离。Kubernetes通过将集群内的资源对象(如Pod、Service等)分配到不同的Namespace中，形成逻辑上的独立空间，以方便不同空间的资源进行隔离使用和管理。

Kubernetes在集群启动之后，通常默认创建如下的Namespace：

default：所有创建时未指定Namespace的资源对象都会被分配到default。
kube-node-lease：集群节点间的心跳维护，v1.13引入。
kube-public：此Namespace下的资源对象可以被所有人访问（包括未认证用户）。
kube-system：所有由Kubernetes系统创建的资源对象都处于这个命名空间。

(二)、Pod

Pod是Kubernetes中可以创建和管理的最小单元。应用程序部署在容器中，而容器必须存在于Pod中。一个Pod中可以有1个或者多个容器。通常情况下不会直接操作Pod，而是通过Pod控制器(例如Deployment)创建或者管理Pod。

(三)、Controller

在Kubernetes中，Pod是最小的管理单元，但是通常情况下Kubernetes不会直接操作Pod，而是通过Pod控制器(Controller)来管理Pod，比如创建Pod、停止Pod、伸缩Pod数量等。当Pod资源在运行中出现故障时，会基于预定的策略重启或者重建Pod。

在Kubernetes中，有很多不同类型的Pod控制器，每种控制器都有其特定的使用场景。

常用的Pod控制器有如下：

ReplicaSet：保障Pod副本数量维持在期望值，并支持Pod数量扩缩容、容器镜像版本升级等。
Deployments：Deployments用于自动管理ReplicaSet，通过控制ReplicaSet来管理Pod，并支持滚动升级、版本回退等。
DaemonSet：在集群中全部或者指定工作节点上运行且仅运行一个Pod副本。当集群新增工作节点时，会新增一个Pod副本；当集群移除工作节点时，这个Pod副本也会被回收。DaemonSet一般用于守护进程类的任务，例如在每个节点上运行日志收集守护进程或者在每个节点上运行监控守护进程。
Job：Job会创建一个或者多个Pod，并执行指定的任务。Job会跟踪记录成功完成任务的Pod个数，当数量达到指定阈值时，任务（即Job）结束。Job可用于执行一次性任务。
Cronjob：Cronjob创建的Pod负责执行周期性任务，如备份、生成监控报告等。
StatefulSet：用来管理有状态应用的资源对象。
HorizontalPodAutoscaler：根据集群负载状态自动水平调整Pod的副本数量，实现削峰填谷功能。

(四)、Service

在Kubernetes中，Pod是应用程序的载体。在集群内部，我们可以通过Pod的IP来访问应用程序。但是Pod的IP并不是固定的，使用IP访问服务并不是很方便。Kubernetes使用Service资源将运行在一个或一组Pod上的应用程序公开，并提供统一的服务访问入口地址。这样客户端就能通过Service的统一入口地址，访问到后端的Pod服务，而不必关心Pod的变化。

Service主要有以下几个类型：

ClusterIP：通过集群的内部IP公开Service，只能在集群内部访问。这个类型是默认值。
NodePort：通过每个工作节点的IP和端口公开Service。通过此方法可以在集群外部访问服务。
LoadBalancer：使用云平台的负载均衡器向外部公开Service。Kubernetes不直接提供负载均衡组件，此模式需要外部云环境支持。
ExternalName： 把集群外部的服务引入集群内部，直接使用。

(五)、Ingress

Kubernetes中的Ingress资源对象，相当于一个七层的负载均衡器，提供从集群外部到集群内部服务的HTTP或者HTTPS路由。Ingress资源对象定义指定的规则，将流量路由最终映射到对应的后端Pod应用程序。通过配置，Ingress可为Service提供外部可访问的URL、对其流量作负载均衡、终止SSL/TLS，以及基于名称的虚拟托管等能力。

Ingress控制器负责完成Ingress的工作，是具体实现反向代理及负载均衡的程序。对Ingress定义的规则进行解析、根据配置的规则来实现请求转发等功能均是由Ingress控制器完成。实现方式有很多，比如Ingress-Nginx控制器等。

Ingress目前已经停止更新，新的功能正在集成至Gateway API中。

(六)、标签(Label)

标签(Label)是附加到Kubernetes资源对象(例如Pod)上的键值对，用于标识、区分资源对象。标签(Label)既可以在创建资源对象时附加，也可以动态添加、修改或者删除。每个资源对象可以定义任意数量的标签(Label)，同一个标签(Label)也可以被添加到任意数量的资源对象上。

常用的标签(Label)示例如下：

版本标签："version":"1.2", "version":"1.3"
环境标签："environment":"test"，"environment":"pro"，"environment":"qa"
架构标签："architecture":"frontend"，"architecture":"backend"

标签(Label)定义完成后，如何选择符合需求的标签(Label)呢？这里就需要使用到标签选择器(Label Selector)。标签选择器(Label Selector)用于查询和筛选拥有指定标签(Label)的资源对象。

当前有两种标签选择器(Label Selector)：

1、基于等值的

environment = pro：表示选择所有包含Label中key="environment "且value="pro"的资源对象。
environment != test：表示选择所有包含Label中key="environment "且value!="test"的资源对象。

2、基于集合的

environment in (qa, pro)：表示选择所有包含Label中key="environment"且value="qa"或者value="pro"的资源对象。
environment not in (qa)：表示选择所有包含Label中key="environment"且value不等于"qa"的资源对象，以及所有没有“environment”键标签的资源对象。

标签(Label)的选择条件可以有多个，即将多个标签选择器(Label Selector)进行组合，使用逗号","进行分隔即可。