kubernetes

发布时间:2023年12月28日

K8S:kubernetes 中间8个字母省略 K8S

自动部署,自动扩展,管理容器化部署的应用程序的一个开源系统

K8S是负责自动化运维管理多个容器化程序的集群,是一个功能强大的容器编排工具。

分布式和集群化的方式进行容器管理

1.15 1.18 现在用的最多的是1.20版本 最新版本1.28

K8S是google的borg系统作为原型 后期由go语言进行编写的开源软件

官网

Kubernetes

GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management

docker微服务,可以满足微服务使用,那么为什么还要使用k8s呢?

  1. 传统的部署方式:一般意义上的二进制部署,安装-运行-运行维护,需要专业的人员,如果出了故障还需要人工重新拉起,如果业务量增大,那么只能水平的进行拓展,再部署一台。
  2. 容器化。可以用dockerfile编写好自定义的容器。基于镜像随时都可以运行。数量少还可以管的过来,数量一旦过多,管理起来较为复杂,并且docker一般是单机运行,没有高可用

K8S的作用:简单,高效的部署容器化的应用

  1. 解决了doocker的单机部署和无法集群化的特点
  2. 解决了随着容器数量的增加,对应增加的管理成本
  3. 容器的高可用,提供了一种容器的自愈机制。
  4. 解决了容器没有预设模板,以及无法快速,大规模部署。以及大规模的容器调度
  5. 提供了集中化配置管理的中心
  6. 解决了容器的生命周期的管理工具
  7. 提供了图形化工具,可以用图形化工具对容器进行管理。

K8S是基于开源的容器集群管理,在docker容器技术的基础之上。

为容器化的应用提供部署,运行,资源调度,服务发现,动态伸缩等一系列完整的功能

大规模容器管理:

  1. 对docker等容器技术从应用的包开始----部署----运行---停止---销毁 全生命周期管理
  2. 集群方式运行,跨机器的容器管理
  3. 解决docker的跨机器运行的网络问题
  4. K8S可以自动修复,使得整个容器集群可以在用户期待的状态下运行。

K8S的特性:

  1. 弹性伸缩,基于命令,或者图形化界面基于CPU的使用情况,自动的对部署的程序进行扩容和缩容。以最小的成本运行服务
  2. 自我修复:如果出现节点故障,它可以自动的重新启动失败的容器,也可以手动的替换和重新部署
  3. 自带服务发现与负载均衡 :K8S为多个容器提供一个统一的访问入口(内部地址和内部的DNS名称),自动负载均衡关联的所有容器

nginx-1

nginx-2 统一IP地址 10.244.0.10:3000 DNS服务名 (三个容器都会有一个统一的地址)

nginx-3

  1. 自动发布和回滚,K8S采用滚动的策略更新应用,如果更新过程中出现问题,可以根据回滚点来进行回滚

nginx-1 先更新1 最新的版本

nginx-2 更新2 如果新版本有问题,可以回滚到老版本,保证服务可以正常使用

nginx-3

? ? 2.集中化的配置管理和密钥管理

K8S集群内的各个组件都是要进行密钥对验证的。但是K8S的安全性不够,核心的组件最好还是不要部署在K8S上,部署一些自定义应用

? ?3.存储编排

可以自动化的把容器部署在节点上

也可以通过命令行或者是yml文件(自定义pod)实现指定节点部署

也可以通过网络存储,NFS ,GFS

? ?4.任务进行批次处理。提供一次性的任务,定时任务,满足需要批量处理和分析的场景

K8S的核心组件:

  1. kube-apiserver:K8S集群之中每个组件都是需要靠密钥对来进行验证,组件之中的通信由apiserver来解决

API是应用接口服务,K8S的所有资源请求和调用的操作都是通过kube-apiserver来完成

所有对象资源的增删改查和监听操作都是kube-apiserver处理完之后再交给etcd来进行。

api-server是K8S所有请求的一个入口服务,api-server接受K8S的所有请求(命令行和图形化界面),然后根据用户的具体请求,通知对应的组件展示或者运行命令

API-server相当于整个集群中的大脑

? ?2.kube-controller-manager:运行管理控制器。是k8s集群中处理常规任务的后台线程。是集群中所有资源对象的自动化控制中心。

一个资源对应一个控制器,controller-manage负责管理这些控制器

  • node controller(节点控制器):负责节点的发现以及节点故障时的发现和响应
  • replication controller(副本控制器):控制关联pod的副本数,可以随时扩缩容
  • Endpoints controller (端点控制器):监听service和对应pod的副本变化。端点就是服务暴露出的访问点 。要访问这个服务,必须要知道他的Endpoints,就是内部每个服务IP的地址+端口
  • service account和roken controllers (服务账户和令牌控制),为命名空间创建默认账户和API访问令牌。

namespace访问不同的命令空间

  • resourcequota controller(资源控制器):可以对命名空间的资源使用进行控制,也可以对pod的资源进行控制。
  • namespace controller:(命名空间的控制器),管理命名空间的生命周期
  • service controller:(服务节点控制器):K8S集群和外部的主机之间一个接口控制器kube-scheduler:资源调度组件,根据调度算法为新创建的pod选择一个合适的node节点。

可以理解为K8S的所有node节点的调度器,部署和调度node

预先策略:人工定制,指定的node节点上部署

优先策略:限制条件

根据调度算法选择一个合适的node,node的节点的资源情况,node的资源控制的情况等等,选一个资源最富裕,负载最小的node来部署,这就是优先策略

  1. ETCD:K8S的存储服务,etcd分布式键值存储系统(key:value)K8S的关键配置,用户配置 ,先通过APIsever调用etcd当中的存储信息,然后再实施(整个集群当中,能对ETCD进行读写权限的,只有API-server)

node组件:

  1. kubelet-node节点的监视器,以及MASTER节点的通讯器,也可以理解为master在node节点上的眼线。

kubelet会定时向API-server汇报自己的node节点上运行服务的状态,API-server会把节点状态保存在ETCD存储当中

接受来自master节点的调度命令。

如果发现自己的状态和master节点的状态不一致,调用docker的接口,同步数据。

对节点上容器的生命周期进行管理,保证节点上的镜像不会占满磁盘空间,退出的容器的资源进行回收。

? 2. kube-proxy:实现每个node节点上的pod网络代理 ,负责节点上的网络规划和四层负载均衡的实现。写入访问映射的规则。负责写入iptables(快淘汰了),IPVS实现服务映射

pod不是容器

kube-proxy:本身不直接给pod提供网络代理,proxy是service资源的载体

pod的IP地址是由kube-flannel来给的

kube-proxy给的是nginx这整个服务集群的网络代理

kube-proxy:实际上代理的是pod集群的网络(虚拟网络)

k8s的每个node节点上都有一个kube-proxy组件

  1. docker:容器引擎,运行容器,负责本机的容器创建和管理。

K8S要创建pod时,通过kube-scheduler调度到节点上(node节点),节点上的kubelet只是docker启动特定的容器

kubelet把容器的信息收集发送给主节点,只需要在主节点发布指令,节点上kubelet就会指示docker拉取镜像,启动或者停止容器

  1. pod是运行在节点上的,它是k8S当中创建或者部署的最小/最简单的一个基本单位,一个pod代表正在集群上运行的一个进程

同一个pod内的每个容器就是一颗豌豆

pod是由一个或者多个容器组成,pod中的容器是共享网络,存储和计算资源 。可以部署在不同的docker主机上

一个pod里面可以运行多个容器,也可以是一个单一的容器。

在生产环境中,一般都是单个容器或者是具有关联关系的多个容器组成一个pod

运行在不同节点的容器

deployment:无状态应用部署,作用就是管理和控制pod,以及replicaset(运行几个容器)管控他的运行状态

replicaset:保证pod的副本数量,副本数量受控于deployment。

部署服务在k8s当中,实际上就是pod,deployment部署的服务就是pod,replicase的就是来定义容器数量

可以保证pod的不可重复性,在当前命名空间不能重复。

官方推荐使用deployment进行服务部署。

daemonset:确保所有节点运行同一类的pod

statefulset:有状态应用部署

job:可以给pod中设置一个一次性任务,运行完及退出

cronjob:一直在运行的一个周期性任务

service:

在K8S整个集群当中,每创建一个pod之后,都会为其中运行的容器分配一个集群内的IP地址,由于业务的变更,容器的数量可能发生变化。IP地址也会发生变化,service的作用就是提供整个pod对外统一的IP地址

service就是一个网关(路由器),通过访问service就可以访问pod内部的容器集群

service能实现负载均衡和代理----kube-proxy---来实现负载均衡

service是k8s微服务的核心,屏蔽了服务的细节,统一的对外暴露的端口 ,真正实现了‘微服务’

service的流量调度:userpace(用户空间,废弃),iptables(即将废弃)。ipvs(目前1.20都用ipvs)

label:标签,K8S特有的一个管理方式,用于分类管理资源对象。

NODE POD service 等等

label:用户可以自定义标签

label选择器:等于,不等于,使用定义的标签名

ingress:K8S集群对外暴露提供访问的接口,属于应用层,访问方式 7层代理,转发的是http请求 http/https

service是四层转发,转发的是流量

https://www.czy.com:80--------> ingress------>service------pod-------容器

namespace:在k8s上,可以通过namespace命令空间的方式来实现资源隔离,项目隔离。

通过namespace可以把集群划分为多个资源不可共享的虚拟集群组

不同命令空间里面的资源名称可以重复的。

数据流向架构图

K8S的网络类型

k8s中的通信模式:

1.pod内部之间容器与容器之间的通信。

在同一个pod中的容器是共享资源和网络,使用同一个网络命名空间

2、同一个node节点之内,不同pod之间的通信。

每个pod都有一个全局的真实的ip地址,同一个node之间的不同pod可以直接使用对方pod的ip地址进行通信

pod1和pod2是通过docker0的网桥来进行通信

3、不同node节点上的node之间如何进行通信?

cni的插件:

cni是一个标准接口,用于容器运行时调用网络插件,配置容器网络,负责设置容器的网络命名空间,IP地址,路由等等参数

fiannel插件:功能就是让集群之中不同节点的docker容器具有全集群唯一的虚拟IP地址。

overlay网络,在底层物流网络的基础之上,创建一个逻辑的网络层。二层+三层的集合,二层是物理网络,三层是逻辑上的网络层

flanne支持的数据转发方式:

1、UDP模式,默认模式,应用转发,配置简单,但是性能最差

2、vxlan,基于内核转发,也是最常用的网络类型(小集群都是用这个)

3、host-gw(性能最好,但是配置麻烦)

UDP模式工作原理:

基于应用层进行转发,由flannel插件来提供路由表,flannel封装数据包,解封装

node都会有一个flannel的虚拟网卡

vxlan:使用的就是overlay的虚拟隧道通信技术。二层+三层的模式

UDP是基于应用层,用户态。

vxlan模式和UDP有相同的地方也有不同的地方

vxlan:flannel提供路由表,内核封装解封装。

flannel1.1接口

安装flannel
每个node节点上操作
[root@node01 opt]# docker load -i flannel.tar 
777b2c648970: Loading layer  5.848MB/5.848MB
815dff9e0b57: Loading layer  11.42MB/11.42MB
2e16188127c8: Loading layer  2.267MB/2.267MB
eb738177d102: Loading layer  49.34MB/49.34MB
b613d890216c: Loading layer   5.12kB/5.12kB
8a984b390686: Loading layer  9.216kB/9.216kB
814fbd599e1f: Loading layer   7.68kB/7.68kB
Loaded image: quay.io/coreos/flannel:v0.14.0
[root@node01 opt]# mkdir -p /opt/cni/bin
[root@node01 opt]# tar -xf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin/

master节点上
[root@master01 opt]# kubectl apply -f kube-flannel.yml 
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
[root@master01 opt]# kubectl get pod -n kube-system
NAME                    READY   STATUS    RESTARTS   AGE
kube-flannel-ds-6r5bh   1/1     Running   0          18s
kube-flannel-ds-xwq6h   1/1     Running   0          18s
[root@master01 opt]# kubectl get pod -o wide -n kube-system
NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE             NOMINATED NODE   READINESS GATES
kube-flannel-ds-6r5bh   1/1     Running   0          43s   192.168.211.30   192.168.211.30   <none>           <none>
kube-flannel-ds-xwq6h   1/1     Running   0          43s   192.168.211.40   192.168.211.40   <none>           <none>

flannel:每个发向容器的数据包进行封装,vxlan通过vtep打包数据,由内核封装数据包--->转发到目标的node节点上。

到了目标节点,还有一个解封装的过程,再发送目标pod,性能有一定的影响

calico插件

采用直接路由的方式,BGP路由。不需要修改报文,统一直接通过路由表转发,路由表会很复杂 ,运行维护的要求比较高

BGP模式的特点:是一种交换路由信息的外部网关协议,可以连接不同的节点,node节点可能不是同一网段,BGP实现可靠的,最佳的,而且是动态的路由选择。自动设别相邻的路由设备

calico不使用overlay,也不需要交换,直接通过虚拟路由实现,每一台虚拟路由都通过BGP转发

核心组件:

felix:也是运行在主机上一个一个的pod,一个进程,k8s daemoset的方式部署的pod

daemont set会在每个node节点部署相同的pod,后台的运行方式

负责宿主机上插入路由规则,维护calico需要的网络设备。网络接口管理,监听,路由等等

BGP Clinet :brid BGP的客户端,专门负责在集群中分发路由规则的信息。每一个节点都会有一个BGP Clinet

BGP协议广播方式通知其他节点的,分发路由的规则,实现网络互通。

etcd:保存路由信息,负责整个网络元素一致性。保证整个网络状态的一致和准确

calico的工作原理:

路由表来维护每个pod之间的通信

创建好pod之后,添加一个设备cali veth pair设备

虚拟网卡:veth pair是一对设备,虚拟的以太网设备

一头连接在容器的网络命名空间 eth0

另一头连接宿主机的网络命名空间 cali

ip地址fenpei: veth pair连接容器的部分给容器分配一个IP地址,这个IP地址是唯一标识,宿主机也会被veth pair分配一个calico网络的内部IP地址 。和其他节点上的容器进行通信

veth设备,容器发出的IP地址通过veth pair设备到宿主机,宿主机根据路由规则的下一跳地址发送到网关(目标宿主机)

fiannel和calico小结

fiannel:配置简单,功能简单,基于overlay叠加网络实现,在物理层的网络上再封装一个虚拟的网络

vxlan是虚拟三层网络

udp是默认模式

vxlan是用的最多的模式 vni类似于vlanid 基于IP进行转发 由fiannel提供路由表,内核封装与解封装

host-gw

由于封装和解封装的功能,对数据传输的性能会有影响,没有网络策略配置的能力 UDP(协议)

默认网段:10.244.0.0/16

calico:功能强大,基于路由表进行转发,没有封装与解封装的过程。具备网络策略的配置能力。但是路由表维护起来比较复杂。

模式:ipip BGP

BGP模式是通过为ip路由表的前缀来实现目标主机的可达性

对比ipip模式。BGP模式没有隧道,BGP模式下,POD的数据包直接通过网卡发送到目标主机

ipip的隧道:隧道进行数据包的封装 ipv5----ipv4

简单的小集群:flannel

扩容,配置网络策略:calico

文章来源:https://blog.csdn.net/2301_78496557/article/details/135202030
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。