Kubernetes介绍

文章目录

---

参考书籍：《Kubernetes权威指南第2版从Docker到Kubernetes实践全接触》
参考文档：https://www.kubernetes.org.cn/docs
参考视频:https://ke.qq.com/course/1709963
​​​新手必须知道的 Kubernetes 架构​​

一、概念

Kubernetes是一个高度自动化的资源控制系统，以​​“一切以服务为中心”​​​作为指导思想，也就是​​Service​​，那么由谁来提供Service

呢？由​​Pod​​​对象，又通过​​Label​​​标签来为Service和Pod建立关联；Pod运行在​​Node​​上，那么Pod又是怎么产生的呢？可以直接定

义创建，也可由​​RC（Replication Controller）​​文件创建。

​​1.1.官方架构图​​

​​非官方架构图​​

二、Master

是集群控制节点，每个K8S集群中都需要一个Master节点来负责整个集群的管理和控制，它是整个集群的“首脑”，运行着三个关键进程：

​​1.kube-apiserver​​

• 提供API，是所有资源增、删、改、查等操作的唯一入口,也是集群控制的入口进程，并把所有操作处理信息存储到etcd中
• 从 etcd 读取（ListWatch）全量数据，并缓存在内存中，绝大部分情况下，apiserver 直接从本地缓存对外提供服务，避免客户端直接请求到etcd；无状态服务，可水平扩展；
• 从最简形式上来说，apiserver 就是挡在 etcd 前面的一个代理（proxy）
  

​​2.kube-controller-manager​​

所有资源对象的自动化控制中心，好比资源对象的“大总管”；
处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。

​​3.kube-scheduler​​

负责资源调度（Pod）的进程，相当于公交公司的“调度室”；
根据调度算法把新创建的Pod部署到对应的Node节点上

调度决策需要考虑的因素包括

Pod 对硬件/软件资源的请求？节点是否报告内存或磁盘压力情况？
该节点是否具有与 pod 规范中的节点选择器匹配的标签？
如果 pod 请求绑定到特定的主机端口，该端口是否已在该节点上占用？
pod 是否容忍节点的污点？
pod 是否指定节点亲和性或反亲和性规则？等。

​​etcd​​

持久化 KV 存储，集群资源（pods/services/networkpolicies/…）的唯一的权威数据（状态）源；

三、Node

除了Master，K8S集群中的其他机器被称为Node节点，它是集群中的工作负载节点，是真正干活的。它有以下一组关键进程:

​​1.kubelet​​

kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，如创建/删除容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。

​​Node​​​节点可以在运行期间动态增加到K8S集群中，默认情况下​​kubelet​​​会向​​Master​​​注册自己，一旦Node被纳入集群管理范围，kubelet进程就会定时向Master节点汇报自身的情况，如操作系统、Docker版本、机器的CPU和内存情况，以及之前有哪些Pod在运行。而当某个Node超时不上报信息，就会被Master判定为​​“失联”​​​，Node的状态被标记为不可用​​（Not Ready）​​​，随后Master会触发​​“工作负载大转移”​​的自动流程。

​​2.kube-proxy​​

实现K8S Service的通信与负载均衡机制的重要组件；
在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。
作为一个全功能的代理服务器管理了两个独立的TCP连接：一个是从容器到kube-proxy,一个是从kube-proxy到负载均衡的目标pod。

​​3.Docker Engine​​

负责本机的容器创建和管理工作

四、Pod

Pod是管理，创建，计划的最小单元。
每个Pod都有一个特殊的​​“根容器”Pause容器​​，Pod里的多个业务容器共享Pause容器的IP和Volume，简化了业务容器之间的通信问题和文件共享问题。

Kubernetes为每个Pod分配了唯一的IP地址，称之为​​Pod IP​​；采用虚拟二层网络技术​​Flannel、Openvswitch​​实现任意两个Pod之间的TCP/IP直接通信。

Pod里的服务进程通过​​Endpoint（PodIP+containerPort）​​对外提供服务。

Pod可以对其能使用的服务器上的计算资源设置限额。以千分之一的CPU配额为最小单元，用m表示。通常一个容器的CPU配额100~300m，即占用0.1～0.3个CPU。CPU配额是一个绝对值，跟服务器CPU的个数无关。
内存的配额也是绝对值，用Mi表示。

Pod有两种类型：

​​1.普通Pod​​

一旦创建，被放入到​​etcd​​中存储，随后被调度到某个具体的Node上进行绑定，并被kubelet进程实例化成一组相关的Docker容器并启动起来。当Pod中的某个容器停止时，K8s会自动检测到这个问题并且重新启动这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

​​2.静态Pod​​

不存放在K8s的etcd存储里，而是存放在某个具体的Node上的一个具体文件中，并且​​只在此Node上启动运行。​​

五、Label

一对 key/value ，被关联到对象上，比如Pod。标签可以用来划分特定组的对象（比如，所有女的），标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的。

​​5.1. Label selector的使用场景​​

1.kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程

2.kupe-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制

3.通过对某些Node定义特定的Label,并且在Pod定义文件中使用NodeSelector这种标签调度策略，Kube-scheduler进程可以实现Pod定向调度的特性

​​5.2. 示例​​

selector:
  matchLabels:
    app: myweb
  matchExpressions:
    - {key: tier, operator: In, values: [frontend]}

六、RC(Replication Controller)

Replication Controller 保证了在所有时间内，都有特定数量的Pod副本正在运行，如果太多了，Replication Controller就杀死几个，如果太少了，Replication Controller会新建几个，和直接创建的pod不同的是，Replication Controller会替换掉那些删除的或者被终止的pod。

只创建一个pod，也要使用Replication Controller。Replication Controller 就像一个进程管理器，监管着不同node上的多个pod,而不是单单监控一个node上的pod。

七、Deployment

为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。相对于RC的一个最大升级是可以随时知道当前Pod“部署”的进度

八、Service

K8S中的Service就是我们经常提起的微服务架构中的一个“微服务”。
K8S为每个Service都分配一个全局唯一的虚拟IP—Cluster IP，并通过DNS做了一个Name与Service的域名映射。

​​1.三个IP​​

a. Node IP

Node节点的IP地址。是物理网卡的IP地址，是一个真实存在的物理网络。

b. Pod IP

它是Docker Engine根据docker0网桥的IP地址段进行分配的，不同Node里面的Pod通过虚拟二层网络进行互相通信。

c. Cluster IP

通过​​NodePort​​的方式来访问Service

九、Volume

是Pod中能够被多个容器访问的共享目录。
Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不丢失。

十、Namespace

1.命名空间在很多情况下用于实现多租户的资源隔离。
K8S集群在启动后会创建一个名为​​“default”​​的NameSpace。

2.权限控制

十一、Annotation

与Label类似，但没有Label那样严格的命名规则，是用户任意定义的“附加”信息，以便于外部工具进行查找。