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

开发 架构
很多小伙伴学习K8S的时候,会被K8S里面的概念搞乱了,望而生畏;而且很多文章里面介绍的时候讲的太专业了。老顾今天来帮小伙伴们梳理一下,讲的不深入,目的是帮忙小伙伴更好的理解,各个概念的由来。

[[387130]]

 目录

  • 前言
  • 架构图
  • Master Node组件
  • Work Node组件
  • Pod发布
  • 反向代理
  • NodePort Service
  • Label与Selector
  • Service发布
  • 总结

前言

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

架构图

5分钟让你理解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对象

  1. apiVersion: v1  #指定api版本,此值必须在kubectl apiversion中 
  2. kind: Pod       #指定创建资源的角色/类型 
  3. metadata:       #资源的元数据/属性   
  4.   name: mc-user #资源的名字,在同一个namespace中必须唯一  
  5. spec:           #specification of the resource content 指定该资源的内容 
  6.   containers:    #容器定义 
  7.     - name: mc-user   #容器的名字   
  8.       image: rainbow/mc-user:1.0.RELEASE    #容器镜像 

我们通过kubectl命令,来创建这个pod

  1. 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发布文件

  1. apiVersion: v1 
  2. kind: Service 
  3. metadata:  
  4.   name: mc-user 
  5. spec:  
  6.   ports: 
  7.     - name: http     #通讯协议 
  8.       port: 8080     #这里的端口和clusterIP对应,即ip:8080,供内部访问。 
  9.       targetPort: 8080   #端口一定要和container暴露出来的端口对应 
  10.       nodePort: 31001  #节点都会开放此端口,此端口供外部调用 
  11.   selector: 
  12.     app: mc-user  #这里选择器一定要选择容器的标签 
  13.   type: NodePort         #这里代表是NodePort类型的 
  14. nodePort的端口范围:30000~32767 

上面是NodePort Service的yaml文件,我们还要修改一个之前的Pod的yaml文件

  1. apiVersion: v1  #指定api版本,此值必须在kubectl apiversion中 
  2. kind: Pod       #指定创建资源的角色/类型 
  3. metadata:       #资源的元数据/属性   
  4.   name: mc-user #资源的名字,在同一个namespace中必须唯一  
  5.   labels:       #标签定义 
  6.     app: mc-user  #标签值 
  7. spec:           #specification of the resource content 指定该资源的内容 
  8.   containers:    #容器定义 
  9.     - name: mc-user   #容器的名字   
  10.       image: rainbow/mc-user:1.0.RELEASE    #容器镜像 

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

总结

今天老顾介绍了K8S的基本概念,以及架构流程;核心的是小伙伴们需要理解Pod、Service、Labels、Selector的这个组件为什么会产生?他们的解决了是什么问题?后续老顾会继续介绍K8S其他的组件概念,希望能够帮助小伙伴们理解,减少K8S的学习难度;谢谢!!!

 

责任编辑:武晓燕 来源: 今日头条
相关推荐

2020-02-19 19:26:27

K8S开源平台容器技术

2023-09-15 08:00:20

Ingress网关Istio

2023-11-27 13:54:00

kubernetes高可用

2023-11-15 13:44:00

k8s-域名日志

2023-09-27 08:09:22

2022-06-07 14:31:09

K8S网络模型容器网络

2023-11-30 08:08:30

k8s优雅停机

2023-09-21 11:28:28

Kubernetes云原生

2009-11-06 16:05:37

WCF回调契约

2021-02-16 09:17:40

VimLinux编辑器

2019-04-11 13:34:24

2009-10-29 11:39:52

ADO.NET连接池

2023-09-24 22:47:42

Kubernetes亲和性

2018-04-26 14:10:08

装机AMDCPU

2023-12-25 08:05:35

2023-09-27 22:33:40

KubernetesK8S

2017-06-07 18:40:33

PromiseJavascript前端

2009-11-05 10:56:31

WCF通讯

2021-04-12 20:42:50

K8S端口内存

2024-01-29 13:03:02

点赞
收藏

51CTO技术栈公众号