[k8s] 第一章十分钟带你理解Kubernetes核心概念

﹏ヽ暗。殇╰゛Y 2022-09-09 11:52 213阅读 0赞

本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。

## 应用部署方式演变 ##

在部署应用程序的方式上，主要经历了三个时代：

*  **传统部署**：互联网早期，会直接将应用程序部署在物理机上
    
    > 优点：简单，不需要其它技术的参与
    > 
    > 缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响
 *  **虚拟化部署**：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境
    
    > 优点：程序环境不会相互产生影响，提供了一定程度的安全性
    > 
    > 缺点：增加了操作系统，浪费了部分资源
 *  **容器化部署**：与虚拟化类似，但是共享了操作系统
    
    > 优点：
    > 
    >  可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
    > 
    >  运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦
    > 
    >  容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

![image-20200505183738289][]

容器化部署方式给带来很多的便利，但是也会出现一些问题，比如说：

*  一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器
 *  当并发访问量变大的时候，怎么样做到横向扩展容器数量

这些容器管理的问题统称为**容器编排**问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：

*  **Swarm**：Docker自己的容器编排工具
 *  **Mesos**：Apache的一个资源统一管控的工具，需要和Marathon结合使用
 *  **Kubernetes**：Google开源的的容器编排工具

![image-20210823234609529][]

## kubernetes简介 ##

![image-20210823234629917][]

kubernetes，是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。

kubernetes的本质是**一组服务器集群**，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

*  **自我修复**：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
 *  **弹性伸缩**：可以根据需要，自动对集群中正在运行的容器数量进行调整
 *  **服务发现**：服务可以通过自动发现的形式找到它所依赖的服务
 *  **负载均衡**：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
 *  **版本回退**：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
 *  **存储编排**：可以根据容器自身的需求自动创建存储卷

![image-20200526203726071][]

实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群：

kubectl create -f single-config-file.yaml

kubectl是和Kubernetes API交互的命令行程序。现在介绍一些核心概念。

## [kubernetes组件][kubernetes] ##

一个kubernetes集群主要是由**控制节点(master)**、\*\*工作节点(node)\*\*构成，每个节点上都会安装不同的组件。

![kubernetes组件][kubernetes 1]

上图可以看到如下组件，使用特别的图标表示Service和Label：

*  Pod
 *  Container（容器）
 *  Label(![label][])（标签）
 *  Replication Controller（复制控制器）
 *  Service（![enter image description here][]）（服务）
 *  Node（节点）
 *  Kubernetes Master（Kubernetes主节点）

### Pod ###

[Pod][]（上图绿色方框）安排在节点上，包含一组容器和卷。同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信。Pod是短暂的，不是持续性实体。你可能会有这些问题：

*  如果Pod是短暂的，那么我怎么才能持久化容器数据使其能够跨重启而存在呢？ 是的，Kubernetes支持[卷][Link 1]的概念，因此可以使用持久化的卷类型。
 *  是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？可以手动创建单个Pod，但是也可以使用Replication Controller使用Pod模板创建出多份拷贝，下文会详细介绍。
 *  如果Pod是短暂的，那么重启时IP地址可能会改变，那么怎么才能从前端容器正确可靠地指向后台容器呢？这时可以使用Service，下文会详细介绍。

### Lable ###

正如图所示，一些Pod有Label（![enter image description here][label]）。一个Label是attach到Pod的一对键/值对，用来传递用户定义的属性。比如，你可能创建了一个"tier"和“app”标签，通过Label（**tier=frontend, app=myapp**）来标记前端Pod容器，使用Label（**tier=backend, app=myapp**）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Replication Controller应用到上面。

### Replication Controller ###

*是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么，能否将Pods划到逻辑组里？*

Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如下面的动画所示：

![Replication Controller][]

如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时很有用。

当创建Replication Controller时，需要指定两个东西：

1.  Pod模板：用来创建Pod副本的模板
2.  Label：Replication Controller需要监控的Pod的标签。

现在已经创建了Pod的一些副本，那么在这些副本上如何均衡负载呢？我们需要的是Service。

### Service ###

*如果Pods是短暂的，那么重启时IP地址可能会改变，怎么才能从前端容器正确可靠地指向后台容器呢？*

Service是定义一系列Pod以及访问这些Pod的策略的一层**抽象**。Service通过Label找到Pod组。因为Service是抽象的，所以在图表里通常看不到它们的存在，这也就让这一概念更难以理解。

现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（**tier=backend, app=myapp**）。*backend-service* 的Service会完成如下两件重要的事情：

*  会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。
 *  现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。

下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

[![3.gif][]][3.gif 1]

有一个特别类型的Kubernetes Service，称为`LoadBalancer`，作为外部负载均衡器使用，在一定数量的Pod之间均衡流量。比如，对于负载均衡Web流量很有用。

### Node ###

节点（上图橘色方框）是物理或者虚拟机器，作为Kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件：

*  Kubelet：是主节点代理。
 *  Kube-proxy：Service使用其将链接路由到Pod，如上文所述。
 *  Docker或Rocket：Kubernetes使用的容器技术来创建容器。

### Kubernetes Master ###

集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，比如Kubernetes API Server。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。

![image-20200406184656917][]

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

1.  首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
2.  一个nginx服务的安装请求会首先被发送到master节点的apiServer组件
3.  apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
    
    在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
4.  apiServer调用controller-manager去调度Node节点安装nginx服务
5.  kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod
    
    pod是kubernetes的最小操作单元，容器必须跑在pod中至此，
6.  一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理

这样，外界用户就可以访问集群中的nginx服务了

## kubernetes概念 ##

**Master**：集群控制节点，每个集群需要至少一个master节点负责集群的管控

**Node**：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行

**Pod**：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器

**Controller**：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

**Service**：pod对外服务的统一入口，下面可以维护者同一类的多个pod

**Label**：标签，用于对pod进行分类，同一类pod会拥有相同的标签

**NameSpace**：命名空间，用来隔离pod的运行环境

![image-20210823234700047][]

[image-20200505183738289]: /images/20220829/8d0cfe79f4b9470084a8d70fe2351244.png
[image-20210823234609529]: /images/20220829/2bad91d5ec914fb9ba94331d0ce6a60f.png
[image-20210823234629917]: /images/20220829/ee58806523264fe987bfbc0d8e920932.png
[image-20200526203726071]: /images/20220829/96473cee2e024cd6b9adab8bdefb87af.png
[kubernetes]: https://kubernetes.io/zh/docs/concepts/overview/components/
[kubernetes 1]: /images/20220829/f712dfe1923f461f9cdff28a46ad4157.png
[label]: /images/20220829/e6c5a5c8e8b249609cd930339b40988e.png
[enter image description here]: /images/20220829/008c3b0690b943a6a6a25f7b42bc735c.png
[Pod]: https://kubernetes.io/zh/docs/concepts/workloads/pods/
[Link 1]: https://kubernetes.io/zh/docs/concepts/workloads/pods/#pod-storage
[Replication Controller]: /images/20220829/a5b0ec8b71084b93adb75eef88d0cb2b.png
[3.gif]: /images/20220829/e697f75fe28549cb8b1896b3d9dde2a9.png
[3.gif 1]: http://dockone.io/uploads/article/20190625/e7a273fcdc03d2417b354b60c253552f.gif
[image-20200406184656917]: https://gitee.com/andanyoung/blog-img/raw/master/img1/image-20200406184656917.png
[image-20210823234700047]: /images/20220829/db4173f8a9844130a84e4c5fe919ee77.png