Kubernetes(K8s)浅谈

目录

一、应用部署方式的发展

二、容器编排

三、K8s集群架构及工作原理

四、K8s中相关概念介绍

---

        Kubernetes是一款容器编排工具，“容器编排”指的是一种基于容器技术的分布式架构方案，了解过docker可能对“容器”一词并不陌生，但“编排”又是何意？为什么需要容器编排？Kubernetes又有什么特殊之处？带着这些问题进入本文吧。

一、应用部署方式的发展

        在了解为什么需要容器编排之前不妨先来看一下应用部署方式的发展历程。

        1、早期部署

        在最开始，我们是直接将项目部署在物理机上，这里的物理机即是有实体的服务器，可以理解为将一个项目部署在了一台电脑上。并且通常只会在一台机器上部署一个应用，因为在这种部署方式下，应用程序的资源使用边界难以定义，如果多个应用部署在一台机器上，可能会因某个应用占用了大部分的资源而导致其他应用无法获取资源的情况。

        这种部署方式优点不用多说，无需其他技术的参与，简单；但它的缺点也显而易见，一个应用就会占用一台机器，成本太高。

        2、虚拟化部署

        进入虚拟化时代，一个物理机上可以运行多个虚拟机，每个虚拟机有自己独立的环境，互不影响，这就为在一台物理机上部署多个应用提供了可能。

        优点：一台服务器上可以部署多个应用，应用之间互不影响，成本和利用率相对于早期部署来说都大大提高；缺点：每个虚拟机都是独立的操作系统，这些操作系统的运行也会产生额外开销，另外通常情况下我们的应用运行环境很可能都是一样的，这样的话我们需要在每个虚拟机上都要搭一遍环境，重复性工作太多，给运维带来不便。

        3、容器化部署

        在虚拟化部署的基础上，人们把关注点放到了在进行虚拟化部署时如何进一步降低资源消耗、减少重复性运维工作、同时保证系统间的隔离性上，这便促使了容器技术的产生。其实容器技术的本质仍然是一种虚拟化技术，不过它与上面提到的虚拟化部署方式不同，这里引用一句网上的概述：

        “容器是通过一种虚拟化技术来隔离运行在主机上不同进程，从而达到进程之间、进程和宿主操作系统相互隔离、互不影响的技术。这种相互孤立进程就叫容器，它有自己的一套文件系统资源和从属进程。”

        容器与虚拟机相比，容器更为轻量级，占用资源少，并且启动时间远小于虚拟机，但从隔离层面来说，虚拟机更为彻底。

        虽然容器技术优点很多，但它也存在着一些问题：大量容器无法管理以及在分布式架构中应用容器无法自动收缩扩展，这也是为什么需要容器编排的原因，由此各种编排工具应运而生。

二、容器编排

        在微服务架构中，我们的服务以容器化的方式部署在服务器上，这些服务少则十个多到百个形成大量的容器化组件，并且这些容器组件之间往往需要相互协作，怎样很好的将这些容器组织在一起就是刚才提到的无法管理问题，所以这个时候有一个管理员出来维护这么多的容器秩序是很有必要的。

        另外在分布式架构中，往往我们的同一个服务会以容器化的方式部署到不同的服务器上，既然是同样的一个服务难道我们需要在每个服务器上都手动的部署一遍吗？这样的话又带来重复性工作，这就是上面提到的无法自动收缩扩展问题。

        容器编排的诞生就是为了解决上述问题，来看看容器编排技术K8s能给我们带来什么：

       1、自动收缩扩展：会对集群中正在运行的容器数量进行自动调整，提升系统的抗压能力。

       2、负载均衡：一个应用如果有多个容器，会对请求进行负载均衡。

       3、存储编排：可以自动创建存储卷。存储卷是定义在pod之上的一个共享目录，它可以被内部所有容器进行挂载，用于记录pod中容器的相关数据，至于pod的概念我们后面再谈。

       4、故障转移：当集群中某个节点挂掉之后，上面原先运行的容器会被自动转移到正常的节点中。

三、K8s集群架构及工作原理

        Kubernetes集群架构总体上是由主节点（master）以及副节点（node）组成，主节点负责整个集群控制，相当于集群的管理员，副节点也称工作节点，我们的应用一般以容器的形式运行在工作节点上，副节点为我们的容器提供运行环境。两个节点都有各自重要的组件，如下：

master节点
API Server：	K8s集群中资源操作的入口，接收运维管理员的命令，管控整个k8s集群。
Scheduler：	负责集群的资源调度，k8s通过Scheduler将pod调度到对应的node节点上。
Controller-Manager：	管理集群的状态，负责应用部署、自动收缩扩展、故障转移等。
Etcd：	相当于一个数据库，存储了集群中master、node、pod等数据信息。

node节点
Kubelet：	接收来自master节点的命令，调用docker完成pod中容器的增删改。
KubeProxy：	负责将运行中的容器对外暴露，让外界能够访问，同时负责K8s集群内部的服务发现与负载均衡。
Docker：	不用多说，负责容器相关的操作。

        下面是一张Kubernetes集群架构图，可以结合上述组件概念进行了解。

        K8s集群管理员用户在部署应用的过程中主要需要创建两个请求：Deployment和Service，现在我们结合上方的架构图来梳理一下这两个请求的创建流程，即K8s架构的工作原理：

        K8s集群管理员用户通过Kubectl提交一个创建Deployment的请求（这个请求一般由yaml文件描述，可参考打包docker镜像推送到远程服务器并部署到k8s），这个请求会通过API Server写入到etcd中，此时Controller Manager发现集群中并没有该Deployment的请求描述的Pod实例，于是根据Deployment描述内容创建出一个Pod对象存入到etcd中，可以发现Deployment相当于Pod的模板，用于定义构造相应的Pod对象。紧接着Scheduler开始发挥作用，它根据内部的调度策略将这些Pod调度到相应的node节点上开始工作，最后还要将这些调度信息写入到etcd中。此时node节点上的Kubelet进程检测到了master分配过来的Pod，于是启动这个Pod开始工作，并负责维护这个Pod的整个生命周期。

        其实通过上述的流程我们的应用就已经在容器中启动好了，但是因为这是分布式集群架构，可能会存在一个服务在不同的服务器上运行了多个Pod的情况，我们怎样将这些不同服务器上的pod关联起来进行通信呢？这就需要接下来创建Service请求，目的是对一组相同的Pod做负载均衡并对外提供访问。

        同样的，K8s集群管理员用户通过Kubectl提交一个创建Service的请求，Controller Manager查询出相关联的Pod实例，生成Service的Endpoints的信息，然后将这些信息写入到etcd，接着node节点上的kube-proxy通过API Server监听到这些Service和Endpoints的信息，当用户发出一个请求时，会先找到Service，再负载均衡到相应的pod中。

        通过以上流程应用就在K8s集群中部署好了，可参考《打包docker镜像推送到远程服务器并部署到k8s》https://blog.csdn.net/h2503652646/article/details/120931329https://blog.csdn.net/h2503652646/article/details/120931329

四、K8s中相关概念介绍

1、Pod

        pod是Kubernetes中最小的控制单元，一个pod中可以存放多个容器，但在实际生产上一个pod中一般只有一个容器，我们的服务就运行在容器之中。

2、Deployment

        Deployment继承了Replication Controller的功能，Replication Controller是复制控制器，主要维护pod的数量及健康状态，Deployment在此基础上还有另外的新特性，如版本记录，多种升级策略等。

3、Service

        在k8s集群中，每个pod都会有一个自己的虚拟ip，pod之间是无法直接通信的，而service的作用就是达到pod与pod之间进行通信的目的，另外，service可以对一组相同服务的pod做负载均衡并对外提供访问。