K8S介绍

Posted 2022-11-15 敲击岁月

K8S介绍

• k8s的特点
• k8s各组件功能
• 工作流程
• service
• ingress
• name
• namespace
• flannel

k8s是用于自动部署，扩展和管理 容器化应用程序的开源系统

k8s的特点

弹性伸缩	使用命令，UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性，业务低峰时回收资源，以最小的成本运行服务
自我修复	在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量，杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断
服务发现和负载均衡	K8S为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使的用户无需考虑容器IP问题
自动发布（默认滚动发布模式）和回滚	K8S采用滚动更新策略更新应用，一次更新一个pod，而不是同时删除所有pod，如果更新过程中出现问题，将回滚更改，保证升级不影响业务
集中化配置管理和密钥管理	管理机密数据和应用程序配置，而不需要把蜜柑数据暴露在镜像里，提高敏感数据安全性，并可以将一些常用的配置存储在k8s中，方便应用程序使用
存储编排，支持外挂存储并对外挂存储资源进行编排	挂载外挂存储系统。无论是来自本地存储，公有云，还是网络存储，都作为集群资源的一部分使用，极大提高存储使用灵活性
任务批处理运行	提供一次性任务，定时任务，满足批量数据处理和分析的场景

k8s各组件功能

etcd	键值对数据库，储存K8S集群所有重要信息（持久化），保存了整个集群的状态
apiserver	所有服务访问统一入口，并提供认证、授权、访问控制、API注册和发现等机制
controller-manager	是与底层云计算服务商交互的管理控制器，维持副本期望数目
scheduler	负责接受任务，调度资源，选择合适的节点进行分配任务，或者说，按照预定的调度策略将Pod调度到相应的机器上，调度策略分为预算策略和优选策略
kubelet	直接跟容器引擎交互实现容器的生命周期管理，同时也负责Volume和网络的管理
kube-proxy	负责为Service提供内部的服务发现和负载均衡，并维护网络规则（写入规则至 IPTABLES、IPVS 实现服务映射访问的）
container-runtime	是负责管理运行容器的软件，比如docker

工作流程

K8S有两种节点，master节点和node节点，还有存储中心etcd。
首先api server接收到创建pod的请求，然后把用户请求写入到etcd中。然后api server会让controller-manager去创建pod。controller-manager会通过api server去读取存储在etcd里面的预设模板，去创建pod。然后通过api server去找scheduler为新创建的pod选择最合适的node节点。scheduler会通过api server读取node节点相关资源。然后通过调度算法计算出pod调度到哪个node节点上运行。然后把信息反馈给api server。api server再去找对应节点的kubelet，由kubelet去创建并维护容器。kubelet会把相关信息反馈给api server，然后api server把相关信息存入etcd中。外部用户通过kube-proxy所承载的service来访问，kube-proxy提供网络代理和四层负载均衡

service

k8s中的service并不是我们常说的服务的含义，更像是网关层，可以看作一组提供相同服务pod的对外访问接口，流量均衡器。
service作用于哪些pod是通过标签选择器来定义的。
在k8s集群中，service可以看作一组提供相同服务的pod的对外访问接口。客户端需要访问的服务就是service对象。每个service都有一个固定的虚拟IP（这个ip也被称为cluster IP),自动并且动态地绑定后面的pod，所有的网络请求直接访问service的虚拟ip，service会自动向后端做转发。
service除了提供稳定的对外访问方式之外。还能起到负载均衡的功能，自动把请求流量分布到后端所有的服务上，service可以做到对客户透明地进行水平扩展，可以通过ipvs来实现网络的转发
service是k8s服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了微服务。比如我们的一个服务A，部署了3个副本，也就是3个pod，对于用户来说，只需要关注一个service的入口就可以，不需要操心究竟应该请求哪一个pod。优势非常明显，一方面外部用户不需要感知因为pod上服务的意外崩溃，k8s重新拉起pod而造成的IP变更，外部用户也不需要感知因升级，变更服务带来的pod替换而造成的IP变化。

ingress

service主要负责k8s集群内部的网络拓扑，集群外部是怎么访问集群内部的？这个时候就需要ingress了。ingress是整个k8s集群的接入口，负责集群内外通讯。
ingress是k8s集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口，典型的访问方式是http/https。
service只能进行第四层的流量调度，表现形式是ip+port。ingress则可以调度不同业务域，不同URL访问路径的业务流量。

name

由于k8s内部，使用资源来定义每一种逻辑概念（功能），所以每种资源，都应该有自己的名称。
资源有api版本(apiservion)，类别(kind)，元数据(metadata)，定义清单(spec)，状态(status)等配置信息
名称通常定义在资源的元数据信息里。在同一个namespace空间中必须是唯一的。

namespace

随着项目增多，人员增加，集群规模的扩大，需要一种能够逻辑上隔离k8s内各种资源的方法，这就是namespace。
namespace是为了把一个k8s集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同namespace内的资源名称可以相同，相同的namespace内的同种资源，名称不能相同
k8s里默认存在的namespace有：default，kube-system，kebe-public等

flannel

可以实现不同node节点上pod相互通信
数据从node1上的pod源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，再由flanneld把pod ip封装到udp中（里面有源pod IP和目的pod IP），根据在etcd保存的路由表通过物理网卡发送给目的node2的flanneld，来进行解封装暴露出udp里的pod IP，最后根据目的pod IP经flannel0虚拟网卡和docker0虚拟网卡转发到目的pod中，完成通信。