Kubernetes:k8s组件
访问的方式是通过kube-proxy匹配iptables功能进行转发的(四层)k8s官方默认提供了四层的代理/负载均衡方式,而我们可以借助于官方后续支持的ingres-nginx提供七层转发/负载均衡。
目录
引言:
基于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 模板、自定义
更多推荐
所有评论(0)