5分钟让你理解K8S必备架构概念，以及网络模型（上）

写在前面

在这用XMind画了一张导图记录Redis的学习笔记和一些面试解析（源文件对部分节点有详细备注和参考资料，欢迎关注个人公众号：阿风的架构笔记 后台发送【导图】拿下载连接， 已经完善更新）：

前言

不少小伙伴学习K8S的时候，会被K8S里面的概念搞乱了，望而生畏；并且不少文章里面介绍的时候讲的太专业了。今天来帮小伙伴们梳理一下，讲的不深刻，目的是帮忙小伙伴更好的理解，各个概念的由来。

架构图

上图中，有两种Node节点，一个是Master、一个是Work。

从字面上来看Work Node就是用来工做的，也就是真正承担服务的机器节点。如服务A部署到K8S后，它的运行环境就在WorkNode节点。

那么Master Node是干吗用的？小伙伴能够认为是用来分配服务到哪一台work node节点的；能够理解为大管家，它会知道现有work node的资源运行状况，决定服务安排到哪些work nodes上。

在Work Node节点上面有2个重要的组件，一个是Pod、一个是Container；

Pod是K8S的最小单元，它里面能够有多个Container。Container就是服务/组件运行的环境。

通常状况下一个Pod只有一个业务服务Container，而其余的Container是系统所须要的容器（其实就是一些进程组件，如网络组件、Volume组件等）。因此通常能够理解为咱们的服务就在Pod里面。

上面只是简单的介绍了K8S基本的架构，以及核心点。

小伙伴们基本使用，理解到这里也就能够了

固然须要深刻了解具体Master和Work节点有哪些组件，以及组件之间的发布流程是什么？继续往下看哦。

Master Node组件

上面中，用户通常采用kubectl命令，以及dashboard控制台去操做k8s。全部的操做都是经过API Server组件，须要持久化的就存储到etcd。Scheduler、Controller Manager组件一直订阅API Server的变化。

总体流程

如用户须要建立服务A的3个pod，那总体流程：

1）经过Kubectl提交一个建立RC的请求，该请求经过API Server被写入etcd中。

2）此时Controller Manager经过API Server的监听资源变化的接口监听到这个RC事件，分析以后，发现当前集群中尚未它所对应的Pod实例，因而根据RC里的Pod模板定义生成一个Pod对象，经过API Server写入etcd。

3）接下来，此事件被Scheduler发现，它当即执行一个复杂的调度流程，为这个新Pod选定一个落户的Work Node，而后经过API Server讲这一结果写入到etcd中。

4）随后，目标Work Node上运行的Kubelet进程经过API Server监测到这个“新生的”Pod，并按照它的定义，启动该Pod。

5）用户的需求是3个pod；那到底有没有启动了3个；是由Controller Manager监控管理的，它会保证资源达到用户的需求。

etcd

用于持久化存储集群中全部的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操做etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。

API Server

提供了资源对象的惟一操做入口，其余全部组件都必须经过它提供的API来操做资源数据，经过对相关的资源数据“全量查询”+“变化监听”，这些组件能够很“实时”地完成相关的业务功能。

Controller Manager

集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工做，好比根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的建立和更新；其余诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工做也是由Controller Manager完成的。

Scheduler

集群中的调度器，负责Pod在集群节点中的调度分配。

Work Node组件

上图右侧是Work Node的组件，总体流程

1）kubelet监听到Api Server的变化后，若是有本work node节点须要建立pod；则会通知Container Runtime组件

2）Container Runtime是管理节点Pod组件，在启动pod时，若是本地没有镜像，则会从docker hub里面拉取镜像，启动容器pod

3）kubelet会把相关信息再传给Api Server

Kubelet

负责本Node节点上的Pod的建立、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。本质Pod的管理是Container Runtime组件负责的

kube-proxy

实现了Service的代理与软件模式的负载均衡器，这个是由于pod的网络ip是常常变化的。这个网络知识，下一篇文章会介绍

Pod发布

上面介绍了K8S总体架构流程，如今先从pod开始，一步步引出K8S的其余概念。

咱们先编辑yaml，定义一个pod对象

apiVersion: v1  #指定api版本，此值必须在kubectl apiversion中
kind: Pod       #指定建立资源的角色/类型
metadata:       #资源的元数据/属性  
  name: mc-user #资源的名字，在同一个namespace中必须惟一 
spec:           #specification of the resource content 指定该资源的内容
  containers:    #容器定义
    - name: mc-user   #容器的名字  
      image: rainbow/mc-user:1.0.RELEASE    #容器镜像
复制代码

咱们经过kubectl命令，来建立这个pod

kubectl apply -f mc-user-pod.yaml
复制代码

咱们mc-user:1.0.RELEASE的镜像就是一个web应用，8080端口；可是咱们发现pod启动后，咱们没法经过pod的ip地址访问此web服务

那怎么才能访问pod呢？

反向代理

在要解决访问pod的问题前，咱们先来看看咱们以前是如何部署网站的？

外网访问咱们内部的网站，通常咱们会在中间部署一个nginx，反向代理咱们的web服务。根据这个思路，K8S体系中也有反向代理这个概念

NodePort Service

K8S中咱们能够采用类型为NodePort的Service实现反向代理

K8S的Service不少，其中NodePort Service是提供反向代理的实现

这样外网就能够访问内部的pod了。实现流程：

1）pod须要打上一个Label标签
2）外部流量请求到NodePort Service，经过Selector 进行路由，
3）NodePort Service根据Label标签进行路由转发到后端的Pod
复制代码

从上面的流程中，其实Service也起到了负载均衡的做用；后端Pod能够有多个，同时打上相同的Label标签，Service会路由转发到其中一个Pod。

Service Type还能够为 LoadBalancer、ClusterIP LoadBalancer：这个是部署到云端（如阿里云）的时候须要用的，也是反向代理+负载均衡的做用，用做外部访问K8S内部。ClusterIP：这个Service是K8S集群内部作反向代理用的

Label与Selector

上图中有2个pod定义了Label为app：nginx；1个pod定义了app：apache；

那么Service的Selector筛选app：nginx，只会路由到nginx的pod。

Service发布

咱们来编写一个NodePort Service发布文件

apiVersion: v1
kind: Service
metadata: 
  name: mc-user
spec: 
  ports:
    - name: http     #通信协议
      port: 8080     #这里的端口和clusterIP对应，即ip:8080,供内部访问。
      targetPort: 8080   #端口必定要和container暴露出来的端口对应
      nodePort: 31001  #节点都会开放此端口，此端口供外部调用
  selector:
    app: mc-user  #这里选择器必定要选择容器的标签
  type: NodePort         #这里表明是NodePort类型的

复制代码

nodePort的端口范围：30000～32767

上面是NodePort Service的yaml文件，咱们还要修改一个以前的Pod的yaml文件

apiVersion: v1  #指定api版本，此值必须在kubectl apiversion中
kind: Pod       #指定建立资源的角色/类型
metadata:       #资源的元数据/属性  
  name: mc-user #资源的名字，在同一个namespace中必须惟一 
  labels:       #标签订义
    app: mc-user  #标签值
spec:           #specification of the resource content 指定该资源的内容
  containers:    #容器定义
    - name: mc-user   #容器的名字  
      image: rainbow/mc-user:1.0.RELEASE    #容器镜像
复制代码

咱们能够利用kubectl命令去分别执行pod和service的yaml文件；这样就能够经过外网直接访问了。http://localhost:31001端口不要忘了是 nodePort定义的端口哦。

总结

今天介绍了K8S的基本概念，以及架构流程；核心的是小伙伴们须要理解Pod、Service、Labels、Selector的这个组件为何会产生？他们的解决了是什么问题？后续会继续介绍K8S其余的组件概念，但愿可以帮助小伙伴们理解，减小K8S的学习难度；谢谢！！！

看完三件事❤️

​ 若是你以为这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙： ​

1. 点赞，转发，有大家的 『点赞和评论』，才是我创造的动力。
2. 关注公众号 『 阿风的架构笔记 』，不按期分享原创知识。
3. 同时能够期待后续文章ing🚀
4. 关注后回复【666】扫码便可获取架构进阶学习资料包