目录

引言:

一、Pod(最小的资源单位)

二、资源清单(YML)

三、Pod 控制器(维护Pod状态,期望值)

四、服务发现(Service同一个访问入口)

service

①servicecontroller

②endpointcontroller

③kube-proxy

五、存储 

5.1 无状态服务:LVS 

5.2 有状态服务:例如数据库(需要持久化)

六、调度器(Scheduler) 

七、标签(Label)

八、命名空间(namespaces)

九、注释(annotations)

十:集群安全        

十一:HELM(K8S 中包的管理工具)

引言:

基于k8s基本概念 在此之上了解K8s的基本组件

一、Pod(最小的资源单位)

一个pod 会封装多个容器组成一个子节点的运行环境 (最小单元,容器的数量2+)

一个Pod中的容器共享网络命名空间(基础容器提供的pause)
Pod是短暂的 (叙述的是其生命周期)

一组容器的集合:基础容器(pause)+ 初始化容器(initcontainers)+业务容器(Maincontainer)(主应用容器+挂斗/副容器)

pod:首先,最小组成单元,是一组容器的集合,应用容器跑在pod资源中的

二、资源清单(YML)

① K8S中资源的概念
② 资源清单格式(资源清单/配置文件):Yaml/语法
③ Pod 生命周期(创建——》发布/暴露(service)——》更新——》回滚——》删除)

三、Pod 控制器(维护Pod状态,期望值)

什么是控制器?对不同的对象及其特性使用不同的方式控制管理

控制器说明:

  • ReplicaSet(RS子控制器):确保预期的Pod副本数量
  • Deployment:无状态应用部署
  • StatefulSet:有状态应用部署(IP得固定)
  • DaemonSet:确保所有Node运行相同服务/应用的一个Pod
  • Job:一次性任务
  • Cronjob:定时任务
  • ingress:管理的是L7层的网络模式(http/https流量)
  • ingress包含:nginx、Haproxy、traffic、istio、kong
  • PV PVC:动态存储

四、服务发现(Service同一个访问入口)

K8S内部的Pod 通讯是以一组私有地址进行通讯的,所以默认情况下无法直接为客户端(服务、用户)提供访问,可以通过Service服务发现,把我们内部的pod资源暴露给客户端访问(以暴露一个ip:端口的方式),让客户端可以通过这个IP:端口的形式访问到K8S内部的多个pod(通常意义上是一个应用的副本集)

通过service这个统一入口/定义的访问策略对外暴露服务,Service 作为一组Pod 的统一访问出入口(定义一组Pod的访问策略),以RR分流算法进行负载均衡,把Pod中的应用服务暴露出来给客户端访问service ——》暴露方式是四层的

访问的方式是通过kube-proxy 匹配iptables功能进行转发的(四层)
k8s官方默认提供了四层的代理/负载均衡方式,而我们可以借助于官方后续支持的ingres-nginx 提供七层转发/负载均衡

ps:为什么需要kube-proxy和service

容器的特点就是快速创建、快速销毁。为了能够访问这些pod,需要引入负载均衡和VTP实现后端真实服务的自动转发和故障漂移

这个负载均衡就是service,VIP就是service IP,service就是一个四层负载均衡。k8s为了实现在集群所有的节点都能访问service,Kube-proxy默认会在所有的节点创建这个VIP,实现负载均衡

service

创建service需要servicecontroller,EndpointController,kube-proxy,三大模块同时协作

①servicecontroller

当一个service对象状态发生变化的时候,Informer都会通知serviceController,创建对应的服务

②endpointcontroller

  • Endpointcontroller会同时订阅service和Pod的增删事件。其功能如下:
  • 负责生成和维护所有endpoint对象的控制器
  • 负责监听service和对应pod的变化
  • 监听到service被删除,则删除和该service同名的endpoint对象
  • 监听到新的service被创建,则根据新建service信息(YAML)获取相关pod列表,然后创建对应endpoint对象
  • 监听到service被更新,则根据更新后的service信息获取相关pod列表,然后更新对应endpoint对象
  • 监听到pod事件,则更新对应的service的endpoint对象,将podip记录到endpoint中
  • 主体:service pod
  • 主体:endpoint对象

功能:定义后端位置和自动发现、自动更新

③kube-proxy

kube-proxy负责service实现,实现了k8s内部service和外部node port到service的访问。

kube-proxy采用iptables的方式配置负载均衡,基于iptables的kube-proxy的主要职责包括两大块:一块是侦听service更新事件,并更新service相关的iptables规则;一块是侦听endpoint更新事件,更新endpoint相关的iptables规则(如KUBE-SVC-链中的规则),然后将包请求转入endpoint对应的Pod。

小结:

serviceController:是控制service来创建对应的Pod关联的规则的

endpointController:是定义后端pod的具体位置,也就是endpoint (upstream +consul的自动发现和更新)

kube-proxy:是用来定叉具体的后端转发和分流规则的

以上组成了一个service所必要的功能

五、存储 

5.1 无状态服务:LVS 

服务不依赖自身的状态,实例的状态数据可以维护在内存中。
任何一个请求都可以被任意一个实例处理。
不存储状态数据,实例可以水平拓展,通过负载均衡将请求分发到各个节点。
在一个封闭的系统中,只存在一个数据闭环。
通常存在于单体架构的集群中。

5.2 有状态服务:例如数据库(需要持久化)

服务本身依赖或者存在局部的状态数据,这些数据需要自身持久化或者可以通过其他节点恢复。
一个请求只能被某个节点(或者同等状态下的节点)处理。
存储状态数据,实例的拓展需要整个系统参与状态的迁移。
在一个封闭的系统中,存在多个数据闭环,需要考虑这些闭环的数据一致性问题。
通常存在于分布式架构中。

简化:

无状态服务:就是没有特殊状态的服务,各个请求对于服务器来说统一无差别处理,请求自身携带了所有服务端所需要的所有参数(服务端自身不存储跟请求相关的任何数据,不包括数据库存储信息

有状态服务:与之相反,有状态服务在服务端保留之前请求的信息,用以处理当前请求,比如session等
 

超简化:

有状态服务:需要持久化,多次请求之间需要共享一些信息
无状态服务:一次性,不需要持久化,每次请求都是一条新的数据

六、调度器(Scheduler) 

K8S会自动完成把一个新的pod 调度到对应的节点(预选/优选算法)对于生产环境上,我们往往会需要将pod创建的过程(比如创建到的节点位置)进行管理

例如:

指定节点位置创建Pod(指定调度)
将不同的Pod创建在一个节点上(亲和)
将不同的Pod 创建在不同的节点上(反亲和)
根据自己的需要,对pod进行节点组装等

七、标签(Label)

Label : 标签,附加到某个资源上,用于关联对象、查询和筛选

创建一个Pod

1、编写pod yml文件(nginx资源怎么跑,用什么环境变量,需不需要资源限制,要调度到哪个节点) label:nginx 
2、把pod 暴露出去,Service——》通过yml文件定义 label:nginx 

通过同一个label标签,进行关联,组合在一起

八、命名空间(namespaces)

namespaces : 命名空间,将对象逻辑上隔离

资源名称空间:网络、user、pid 

default 
kube-system

kube-node-release

kube-public

在同一个名称空间的pod可以通信(创建pod不指定默认在default里)

名称空间限制pod数量

九、注释(annotations)

Annotations :注释(描述性信息)

十:集群安全        

认证、鉴权、访问控制、原理及流程
从搭建集群,就需要用到加密,CA认证
管理和控制,必须先通过认证/授权,才能进行管理
跑的一些应用,nginx、squid ——》需要一些访问控制策略

十一:HELM(K8S 中包的管理工具)

类似linux里面yum 
helm 安装 magodb
helm 模板、自定义

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐