目录

1. 前言
2. 架构图
3. Master Node组件
4. Work Node组件
5. Pod发布
6. 反向代理
7. NodePort Service
8. Label与Selector
9. Service发布
10. 总结

前言

很多小伙伴学习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的学习难度；谢谢！！！

---End---

老顾的微服务网关分享课程，请大家多多支持

推荐阅读

大厂如何基于binlog解决多机房同步mysql数据（一）？

大厂如何基于binlog解决多机房同步mysql数据（二）？

基于binlog的canal组件有哪些使用场景（三）？

基于binlog日志之canal企业应用及高可用原理（四）

可用于大型应用的微服务生态灰度发布如何实现？

一线大厂级别公共Redis集群监控，细化到每个项目实例

Sharding-jdbc的实战入门之水平分表（一）

Sharding-Jdbc之水平分库和读写分离（二）

a、dubbo如何处理业务异常，这个一定要知道哦！

b、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（一）

c、企业级SpringBoot应用多个子项目配置文件规划、多环境支持（二）

d、企业级SpringBoot应用多个子项目配置文件之配置中心（三）

e、利用阿里开源工具进行排查线上CPU居高问题

f、阿里二面：如何快速排查死锁？如何避免死锁？

g、微服务分布式架构中，如何实现日志链路跟踪？

h、网关如何聚合各个微服务的接口文档？

i、Kubernetes之POD、容器之间的网络通信

j、K8S中的Service的存在理由

k、企业微服务项目如何进入K8S的全过程

l、阿里开源项目Sentinel限流、降级的统一处理

m、大厂二面：Redis的分布式布隆过滤器是什么原理？

1、基于RocketMq的SpringCloud Stream框架实战入门

2、如何搭建消息中间件应用框架之SpringCloud Stream

3、面试必备：网关异常了怎么办？如何做全局异常处理？

4、Gateway网关系列(二)：SpringCloud Gateway入门实战，路由规则

5、Gateway网关系列开篇：SpringCloud的官方网关Gateway介绍

6、API网关在微服务架构中的应用，这一篇就够了

7、学习Lambda表达式看这篇就够了，不会让你失望的哦（续篇）

8、Lambda用在哪里？几种场景？

9、为什么会出现Lambda表达式，你知道吗？

10、不说“分布式事务”理论，直接上大厂阿里的解决方案，绝对实用

11、女程序员问到这个问题，让我思考了半天，Mysql的“三高”架构

12、大厂二面：CAP原则为什么只能满足其中两项？而不能同时满足

13、阿里P7二面：聊聊零拷贝的原理

14、秒杀系统的核心点都在这里，快来取

15、你了解如何利用token方式实现分布式Session吗？

16、Mysql索引结构演变，为什么最终会是那个结构呢？让你一看就懂

17、一场比赛涉及到的知识，用通俗易通的方式介绍并发协调

18、企业实战Redis全方面思考，你思考了吗？

19、面试题：Thread的start和run的区别

20、面试题：什么是CAS？CAS的作用以及缺点

21、如何访问redis中的海量数据？避免事故产生

22、如何解决Redis热点问题？以及如何发现热点？

23、如何设计API接口，实现统一格式返回？

24、你真的知道在生产环境下如何部署tomcat吗？

25、分享一线互联网大厂分布式唯一ID设计 之 snowflake方案

26、分享大厂分布式唯一ID设计方案，快来围观

27、你想了解一线大厂的分布式唯一ID生成方案吗？

28、你知道如何处理大数据量吗？(数据拆分篇)

29、如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)

30、你知道怎么分库分表吗？如何做到永不迁移数据和避免热点吗？

31、你了解大型网站的页面静态化吗？

32、你知道如何更新缓存吗？如何保证缓存和数据库双写一致性？

33、你知道怎么解决DB读写分离，导致数据不一致问题吗？

34、DB读写分离情况下，如何解决缓存和数据库不一致性问题？

35、你真的知道怎么使用缓存吗？

36、如何利用锁，防止缓存击穿？重构思想的重要性

37、海量订单产生的业务高峰期，如何避免消息的重复消费？

38、你知道如何保障生产端100%消息投递成功吗？

39、微服务下的分布式session该如何管理？

40、阿里二面：filter、interceptor、aspect应如何选择？很多人中招

41、互联网架构重要组员CDN，很多高级开发都没有实操过，来看这里

42、阿里二面：CDN缓存控制原理，看看能不能难住你

43、SpringCloud Alibaba之Nacos多环境多项目管理

44、SpringCloud Alibaba系列之Nacos配置中心玩法

45、SpringCloud Alibaba之Nacos注册中心

46、SpringCloud Plus版本之SpringCloud Alibaba

47、SpringCloud Alibaba之Nacos集群、持久化

48、SpringCloud Alibaba之Nacos共享配置、灰度配置

49、SpringCloud Alibaba之Sentinel工作原理

50、SpringCloud Alibaba之Sentinel流控管理

51、SpringCloud Alibaba之Sentinel降级管理

52、SpringCloud Alibaba之Sentinel热点参数限流

53、SpringCloud Alibaba之Sentinel的API实战