[云原生] 初识Kubernetes

一、k8s的由来及应用

1.1  k8s的简介 

  Kubernetes，词根源于希腊语的 舵手、飞行员。在国内又称k8s（因为k和s之间有8个字母，所以得名。“国内程序员的幽默”）。用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。可以理解成 K8S 是负责自动化运维管理多个容器化程序（比如 Docker）的集群，是一个生态极其丰富的容器编排框架工具。

K8S由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经GO语言延用Borg的思路重写并捐献给CNCF基金会开源。

云原生基金会（CNCF）于2015年12月成立，隶属于Linux基金会。CNCF孵化的第一个项目就是Kubernetes，随着容器的广泛使用，Kubernetes已经成为容器编排工具的事实标准。

官网：
https://kubernetes.io

GitHub：
https://github.com/kubernetes/kubernetes

1.2 传统后端部署与k8s 的对比

传统部署

 传统的后端部署办法：把程序包（包括可执行二进制文件、配置文件等）放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。

此时一旦服务的请求量上来，已部署的服务响应不过来，传统的做法往往是，如果请求量、内存、CPU超过阈值做了告警，运维人员马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。这样问题就出现了：从监控告警到部署服务，中间需要人力介入！ 没有办法自动完成服务的部署、更新、卸载和扩容、缩容

k8s的部署 

  上述传统后端部署的问题，就是k8s所要解决的问题。自动化运维管理容器化（Docker）程序。K8S是Google开源的容器集群管理系统，在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 

1.3 k8s的主要功能

● 跨主机编排容器。
● 更充分地利用硬件资源来最大化地满足企业应用的需求。
● 控制与自动化应用的部署与升级。
● 为有状态的应用程序挂载和添加存储器。
● 线上扩展或缩减容器化应用程序与它们的资源。
● 声明式的容器管理，保证所部署的应用按照我们部署的方式运作。
● 通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。
● 为多个容器提供服务发现和负载均衡，使得用户无需考虑容器IP问题。 

二、 k8s的集群架构与组件 

2.1 k8s的集群机构的简单介绍 

K8S 是属于主从设备模型（Master-Slave 架构），即有 Master 节点负责集群的调度、管理和运维，Slave 节点是集群中的运算工作负载节点。
在 K8S 中，主节点一般被称为 Master 节点，而从节点则被称为 Worker Node 节点，每个 Node 都会被 Master 分配一些工作负载。

Master 组件可以在群集中的任何计算机上运行，但建议 Master 节点占据一个独立的服务器。因为 Master 是整个集群的大脑，如果 Master 所在节点宕机或不可用，那么所有的控制命令都将失效。除了 Master，在 K8S 集群中的其他机器被称为 Worker Node 节点，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上去。

2.2 K8S的核心组件 

1、Master组件

（1） Kube-apiserver

用于暴露 Kubernetes API，任何资源请求或调用操作都是通过 kube-apiserver 提供的接口进行。以 HTTP Restful API 提供接口服务，所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给 Etcd 存储。

可以理解成 API Server 是 K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具）， 然后根据用户的具体请求，去通知其他组件干活。可以说 API Server 是 K8S 集群架构的大脑。

（2）Kube-controller-manager 

运行管理控制器，是 K8S 集群中处理常规任务的后台线程，是 K8S 集群里所有资源对象的自动化控制中心。
在 K8S 集群中，一个资源对应一个控制器，而 Controller manager 就是负责管理这些控制器的。

由一系列控制器组成，通过 API Server 监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个 Node 意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

这些控制器主要包括：

（3）Kube-scheduler 

是负责资源调度的进程，根据调度算法为新创建的 Pod 选择一个合适的 Node 节点。

可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。
•  预选策略（predicate）
• 优选策略（priorities）

API Server 接收到请求创建一批 Pod ，API Server 会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API Server 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点。

比如运行这个 Pod 需要 2C4G 的资源，Scheduler 会通过预选策略过滤掉不满足策略的 Node 节点。Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，如果某个 Node 节点的资源不足或者不满足 预选策略的条件则无法通过预选。预选阶段筛选出的节点，在优选阶段会根据优选策略为通过预选的 Node 节点进行打分排名， 选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。

2、配置存储中心etcd

etcd：K8s的存储服务，是分布式键值存储系统，最少三台最优为8G内存。存储了K8S的关键配置和用户配置并且持久化保存，K8s中仅有API server才具有读写权限，其他组件必须通过API server的接口才能读写数据。端口为2379和2380,2379用于对外客户的提供通信，2380用于对集群服务器间内部的通信

3、Node组件

① Kubelet

Node节点的监视器，以及与Master节点的通讯器。Kubelet是Master节点安插在Node节点的眼线，会定时向API server汇报自己Node节点上运行服务的状态，并接受来自Master节点的指示采取调整措施(例如创建Pod)。

从Master节点获取自己节点上Pod的期望状态(例如运行什么容器、运行的副本数量、网络等)，直接与容器引擎交互实现容器的声明周期管理，如果自己节点上的Pod状态与期望状态不一致调用对应容器的接口达到预期状态

管理镜像和容器的清理工作，保证节点上镜像不会占满磁盘，退出的容器不会占用太多的资源

② Kube-Proxy

每个节点上实现Pod网络代理，是K8S Service 资源的载体，负责维护网络规则和四层负载均衡工作，负责写入规则至iptables、ipvs等实现服务映射访问的。

本身不是直接给Pod提供网络，Pod的网络是由Kubelet提供的，实际上维护的是虚拟的Pod集群网络

Kube-apiserver通过监控Kube-Proxy 进行对Kubernetes Service的更新和端点的维护。

在K8S集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都会运行一个Kube-proxy 组件。

③ docker或rocker

容器引擎，运行容器，负责本机的容器创建和管理工作

4、K8S三种负载均衡模式 

① namespace

② iptables(默认使用 )

③ ipvs(此模式更快，所有安装是需要更改为此模式。内核运行更快，性能更好。 )

 5、K8S架构工作流程

①运维人员操作Kubectl命令向API server发送任务请求，先到Auth进行鉴权认证，然后进到API Server中，API Server存储操作到Etcd

②然后API Server根据Etcd中用户执行的操作调用 controller manager对应的控制器进行操作，例如创建

③controller manager通过调用创建控制器到API Server创建replication副本，APIserver将操作存到Etcd中，API Server再调用Scheduler进行算法选择为Pod选择最合适的节点创建，Scheduler需要通过API Server在node节点上的Kubelet进行预选策略和优选策略选择最优的node节点APIserver将动作保存到Etcd中

④Scheduler选择完节点后通过APIserver的Kubelet在对应的node节点上创建Pod，并通知对应node节点的doker在Pod中创建容器

⑤容器需要对外提供服务时，通过node节点的Kube-Proxy代理对外映射端口信息，Kube-proxy进来后通过service负载均衡器分发到容器上，访问容器是根据Label标签访问的。

6、K8S的核心概念

包含：Pod、Label、Service、Replication、Controller。等

① Pod

是K8s创建或者部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程，Pod里面可以放很多容器。一个Pod由一个或多个容器组成，Pod中的容器共享网络、存储和计算资源在同一台Docker主机上运行，一个Pod可以运行多个容器，又称为边车模式(sidecar)。生产中一般一个Pod就一个容器或者是有多个强关联性互补的容器

同一个Pod直接的容器可以通过localhost互相访问，并且可以挂载Pod内所有数据卷。不同Pod之间的容器不能用localhost访问，也不能挂载Pod内所有数据卷。

② Pod控制器

Pod控制器是启动Pod的一种模板，用来保证在K8S里启动Pod应始终按照用户的预期运行

Deployment：无状态应用部署即无论谁来访问都是一样的例如http网页

有状态协议：需要持久化

无状态协议：一次性的不需要持久化，每一次请求都是一条新的数据

Replicaset：受控于Deployment，确保预期的Pod副本数量，Replicaset的通就是管理和控制Pod管理他们好好工作，若发现某个Pod不行了就找个新的Pod来做替换。

Daemonset：确保所有节点运行同一类Pod，保证每个节点上都有一一个此类Pod运行，通常用于实现系统级后台任务。

Statefulset：有状态应用部署

Job：一次性任务。根据用户的设置，Job 管理的Pod把任务成功完成就自动退出了。

Cronjob：周期性计划性任务

 7、Label标签

①标签是K8s特色的管理方式便于分类管理资源对象

②label可以附加到各种资源对象上，例如：node、Pod、service、Rc等，用于关联对象、查询和筛选

③一个label是一个key-value的键值对，key-value都由用户自定义

④一个资源对象可以定义任意数量的label，同一个label也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除

⑤可以通过给指定的资源对象捆绑一个或多个不通的label，实现多维度的资源分组管理功能

 8、Label选择器(Label selector)

①给某个资源对象定义一个Label，就相当于给他打开了一个标签，随后可以通过标签选择器(Labelselector)查询和筛选拥有某些Label的资源对象。

②标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在。

9、Service

K8S集群中每个Pod会被分配一个单独的ip地址，但是由于Pod是有生命周期的(可以被创建而且销毁后不会再重启)，随时可能会因为业务ip的变更，导致这个ip地址会随着Pod的销毁而消失

Service就是用来解决这个问题的核心概念：

Service：通过标签选择器关联具有对应Lable的Pod，再把相关的Pod IP加入自己的Endpoints当中，service根据Endpoints里的Ip进行转发

不是服务的含义，更像是一个网关层、流量均衡器、Service作用于那些Pod由标签选择器来定义。

service可以看作一组提供相同服务的Pod的对外访问接口，客户端需要访问的服务就是Service的对象，每个Service都有一个虚拟的ip，会自动向后端做转发。

负载均衡功能：自动把请求流量分配到后端所有的服务上，可以对客户端透明的做水平扩展，实现此功能的关键是Kube-proxy，Kubeproxy运行在每个节点上监听APIserver中服务对象的变化，三种流量调度模式：userspace、iptables(利用的nat默认但不常用)、ipvs(推荐，性能最好)，实现网络的转发

Service是K8s服务的核心，屏蔽了服务细节，统一了对外暴露服务接口，真正做到了微服务。用户只需要关注一个Service入口即可，不需要关注具体请求那个Pod。用户不会感知因为Pod上服务的意外崩溃K8S重新拉起Pod而导致的ip变更，也不会感知到因服务升级、服务变更等带来的Pod替换而导致的IP变化。

10、Ingress

service负责K8s集群内部的网络拓扑(四层)、Ingress负责集群外部的网络(七层)，将客户的请求转发给对应的service处理，然后service根据label负载均衡给Pod

11、Service“服务” 

在K8S的集群里，虽然每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的（它们可以被创建，而且销毁之后不会再启动），随时可能会因为业务的变更，导致这个 IP 地址也会随着 Pod 的销毁而消失。

Service 就是用来解决这个问题的核心概念。K8S 中的 Service 并不是我们常说的“服务”的含义，而更像是网关层，可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
Service 作用于哪些 Pod 是通过标签选择器来定义的。
在 K8S 集群中，Service 可以看作一组提供相同服务的 Pod 的对外访问接口。客户端需要访问的服务就是 Service 对象。每个 Service 都有一个固定的虚拟 ip（这个 ip 也被称为 Cluster IP），自动并且动态地绑定后端的 Pod，所有的网络请求直接访问 Service 的虚拟 ip，Service 会自动向后端做转发。
Service 除了提供稳定的对外访问方式之外，还能起到负载均衡（Load Balance）的功能，自动把请求流量分布到后端所有的服务上，Service 可以做到对客户透明地进行水平扩展（scale）。
而实现 service 这一功能的关键，就是 kube-proxy。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化， 可通过以下三种流量调度模式： userspace（废弃）、iptables（濒临废弃）、ipvs（推荐，性能最好）来实现网络的转发。

Service 是 K8S 服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。比如我们的一个服务 A，部署了 3 个副本，也就是 3 个 Pod； 对于用户来说，只需要关注一个 Service 的入口就可以，而不需要操心究竟应该请求哪一个 Pod。
优势非常明显：一方面外部用户不需要感知因为 Pod 上服务的意外崩溃、K8S 重新拉起 Pod 而造成的 IP 变更， 外部用户也不需要感知因升级、变更服务带来的 Pod 替换而造成的 IP 变化。

12、Name 

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