Kubernetes基础概念

        Kubernetes 是谷歌以 Borg 为前身，基于谷歌 15 年的生产环境经验开源的一个项目。Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 致力于提供跨主机集群的自动部署、扩展、高可用以及运行应用程序容器的平台，其遵循主从式架构设计、组件可以分为工作节点(Node)组件，和控制平面组件。Kubernetes Master 是集群的主要控制单元，用于管理工作负载并指导整个系统的通信。Kubernetes 控制平面由各自的进程组成，没个组件都可以在单个节点上运行，也可以在支持高可用集群的多个节点上运行。

一、为什么需要Kubernetes

        很多人会有疑问，有了 Docker 为什么还用 Kubernetes?
        在业务开始进行容器化时，前期需要容器化的项目可能并不多，涉及的容器也并不多，此时基于 Docker 容器直接部署至宿主机也能实现基本的需求。但是随着项目越来越多，管理的容器也会越来越多，此时使用“裸容器”部署的方式管理起来就显得很吃力，并且随着业务量的增加，会明显体会到“裸容器”的不足。比如:
        宿主机宕机造成该宿主机上的容器不可用，且无法自动恢复。
        容器明明在运行，接口就是不通(健康检查做得不到位)。
        应用程序部署、回滚、扩缩容困难。
        成百上千的容器和涉及的端口难以维护。
        由于公司业务多，开发环境、测试环境、预生产环境和生产环境都是隔离的，而且除了生产环境，为了节省成本，其他环境可能没有进行日志收集。在没有用Kubernetes 的时候，查看线下测试的日志，需要开发者或测试人员找到对应的机器，再找到对应的容器，才能查看对应的日志。在使用 Kubernetes 之后，开发人员和测试者直接在 Kubernetes 的 Dashboard 上找到对应的namespace，即可定位到业务所在的容器，然后可以直接通过控制台查看到对应的日志，大大降低了操作时间。
        把应用部署到 Kubernetes 之后，代码的发布、回滚以及蓝绿发布、金丝雀发布等变得简单可控，不仅加快了业务代码的迭代速度，而且全程无须人工干预。生产环境可以使用jenkins、git等工具进行发版或回滚等。从开发环境到测试环境，完全遵守一次构建，多集群、多环境部署，通过不同的启动参数、不同的环境变量、不同的配置文件区分不同的环境。
        在使用服务网格后，开发人员在开发应用的过程中，无须去关心代码的网络部分，这些功能被服务网格实现，让开发人员可以只关心代码逻辑部分，即可轻松实现网络部分的功能，比如断流、分流、路由、负载均衡、限速和触发故障等功能。
        在测试过程中，可能同时存在多套环境，当然也会创建其他环境或临时环境，之前测试环境的创建需要找运维人员或者自行手工搭建。在迁移至 Kubernetes 集群后，开发人员如果需要新的环境，无须再找运维，只需要在 jenkins 上点点鼠标即可在 Kubernetes 集群上创建一套新的测试环境。
        在没有使用 Kubernetes 时，业务应用的扩容和缩容需要人工去处理，从采购服务器、上架到部署依赖环境，不仅需要大量的人力物力，而且非常容易在中间过程出现问题，又要花大量的时间去查找问题。成功上架后，还需要在前端负载均衡添加该服务器，而如今，可以利用 Kubernetes的弹性计算一键式扩容和缩容，不仅大大提高了运维效率，而且还节省了不少的服务器资源，提高了资源利用率。
        在反向代理配置方面，可能对nginx的配置规则并不熟悉，一些高级的功能也很难实现，但是在 Kubernetes 上，利用 Kubernetes 的 ingress 即可简单的实现那些复杂的逻辑，并且不会再遇到 nginx 少加一个斜杠和多加一个斜杠的问题。
        在负载均衡方面，之前负载均衡可能是 nginx、LVS、Haproxy、F5 等，云上可能是云服务商提供的负载均衡机制。每次添加和删除节点时，都需要手动去配置前端负载均衡，手动去匹配后端节点。在使用 Kubernetes 进行编排服务时，使用 Kubernetes 内部的 Service 即可实现自动管理节点，并且支持自动扩容、缩容。
        在高可用方面，Kubernetes 天生的高可用功能让运维人员彻底释放了双手，无需再去创建各类高可用工具，以及检测脚本。Kubernetes 支持进程、接口级别的健康检查，如果发现接口超时或者返回值不正确，会自动处理该问题。
        在中间件搭建方面，根据定义好的资源文件，可以实现秒级搭建各类中间件高可用集群，且支持一键式扩容、缩容，如 Redis、RabbitMQ、Zookeeper 等，并且大大减少了出错的概率。
        在应用端口方面，传统架构中，一台服务器可能跑了很多进程，每个进程都有一个端口，要认为的去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙，在Kubernetes 中,端口统一管理、统一配置,每个应用的端口都可以设置成一样的,之后通过 Service进行负载均衡，大大降低了端口管理的复杂度和端口冲突。
        无论是对于开发人员、测试人员还是运维人员，Kubernetes 的诞生不仅减少了工作的复杂度还减少了各种运维成本。

二、Kubernetes架构分析

        由图可知，Kubernetes 架构可以简单分为主(master)节点，从(worker/node)节点和数据库 ETCD。其中主节点为集群的控制单元，一般不会运行业务应用程序，主要包含的组件Kube-APIServer、Kube-ControllerManager、Kube-Scheduler。从节点为工作节点，也就是部署应用程序容器的节点，主要包含的组件有 Kubelet、Kube-Proxy、容器，当然如果 master 节点也要部署容器，也会包含这两个组件。 

1.master节点的组件

        master 节点是 Kubernetes 集群的控制节点,在生产环境中不建议部署集群核心组件外的任何容器(在 kubeadm 安装方式下，系统组件以容器方式运行在 master 节点的宿主机上;二进制安装方式下，系统组件以守护进程的方式运行，master节点可以不运行任何容器)，公司业务程序的容器是不建议部署在 master 节点上，以免升级或者维护时对业务在成影响。

(1)APl server

        API server 提供了集群网关，是整个集群的控制中枢，提供集群中各个模块之间的数据交换并将集群信息存储到 ETCD 集群中。同时，它也是集群管理、资源配额、提供完备的集群安全机制的入口，为集群各类资源对象提供增删改査。API server 在客户端对集群进行访问， 客户端需要通过认证，并使用 API server 作为访问节点和 pod (以及服务)的堡垒和代理/通道。
        API 服务器公开 Kubernetes API。
        REST/kubectl 的入口点--它是 Kubernetes 控制平面的前端,
        它跟踪所有集群组件的状态并管理它们之间的交互。
        它旨在水平扩展。
        它使用 YAML/JSON manifest 文件。
        它验证和处理通过 API 发出的请求。

(2)Scheduler

        Scheduler 主要功能是资源调度，将 pod 调度到对应的主机上。依据请求资源的可用性、服务请求的质量等约束条件，K8s也支持用户自己提供的调度器。
        它将 pod 调度到工作节点。
        它监视 api-server 以查找没有分配节点的新创建的 Pod，并选择一个健康的节点让它们运行。
        如果没有合适的节点，则Pod 将处于挂起状态，直到出现这样一个健康的节点。
        它监视 API Server 的新工作任务。

(3)Controler Manager

        Controller Manager 负责维护集群的状态，比如故障检测、内存垃圾回收、滚动更新等，也执行 API 业务逻辑;K8s 默认提供 replication controller、controller、daemonsetcontroller 等控制器。
        它监视它管理的对象的期望状态并通过 API 服务器监视它们的当前状态。
        采取纠正措施以确保当前状态与所需状态相同。
        它是控制器的控制器。
        它运行控制器进程。从逻辑上讲，每个控制器都是一个单独的进程，但为了降低复杂性，它们都被编译成一个二进制文件并在单个进程中运行。

(4)etcd

        etcd用于可靠的存储集群的配置数据，是一种持久性、轻量型、分布式的键值数据存储组件。可以理解为一种分布式的非关系型数据库。etcd 是集群的状态， K8s 默认使用分布式的 etcd 集群整体存储用来实现发现服务和共享配置集群的所有状态都存储在etcd 实例中，并具有监控的能力，因此当 etcd 中的信息发生变化时，能够快速地通知集群中相关的组件。
        它是一个一致的、分布式的、高度可用的键值存储。
        它是有状态的持久存储，用于存储所有 Kubernetes 集群数据(集群状态和配置)
        它是集群的真相来源。
        它可以是控制平面的一部分，也可以在外部进行配置。

2.Node节点包含的组件

        Node 节点也被成为 worker 节点，是主要负责部署容器的主机，集群中的每个节点都必须具备容器的 Runtime(运行时)，比如docker
        kubelet 作为守护进程运行在 Node 节点上,负贵监听该节点上所有的 pod，同时负责上报该节点上所有 pod 的运行状态，确保节点上的所有容器都能正常运行。当 Node 节点宕机或故障时，该节点上运行的 pod 会被自动转移到其他节点上。

(1)容器进行时

        docker 引擎是本地的容器运行时环境,负责镜像管理以及 pod 和容器的真正运行。K8s 本身并不提供容器运行时环境，但提供了接口，可以插入所选择的容器运行时环境，目前支持 Docker 和rkt .

        容器运行时是负责运行容器(在Pod 中)的软件。
        为了运行容器，每个工作节点都有一个容器运行时引擎。
        它从容器镜像注册表(container image registry)中提取镜像并启动和停止容器。

        Kubernetes 支持多种容器运行时:
        Docker
        containerd
        CRI-0
        Kubernetes CRI(Container Runtime Interface,容器运行时接口)的任何实现。

(2)kubelet

        kubelet 是 node 节点上最主要的工作代理，用于汇报节点状态并负责维护 pod 的生命周期,也负责 volume(CVI)和网络(CNI)的管理。kubelet 是pod 和节点API 的主要实现者，负责驱动容器执行层。作为基本的执行单元，pod 可以拥有多个容器和存储卷，能够方便地在每个容器中打包一个单一的应用，从而解耦了应用构建时和部署时所关心的事项，方便在物理机或虚拟机之间进行迁移。
        它是在集群中的每个节点上运行的代理。
        它充当API 服务器和节点之间的管道。
        它确保容器在 Pod 中运行并且它们是健康的。
        它实例化并执行 Pod。
        它监视 API Server 的工作任务。
        它从主节点那里得到指令并报告给主节点。 

(3)kube-proxy 代理

        kube-proxy 代理对抽象的应用地址的访问，服务提供了一种访问一群 pod 的途径，kube-proxy 负责为服务提供集群内部的服务发现和应用的负载均衡(通常利用 iptables 规则)，实现服务到 pod 的路由和转发。此方式通过创建一个虚拟的 IP 来实现，客户端能够访问此 IP，并能够将服务透明地代理至 pod。
        它是网络组件，在网络中起着至关重要的作用。
        它管理 IP 转换和路由。
        它是运行在集群中每个节点上的网络代理。
        它维护节点上的网络规则。这些网络规则允许从集群内部或外部与Pod 进行网络通信
        它确保每个 Pod 获得唯一的 IP 地址。
        这使得 pod 中的所有容器共享一个 IP 成为可能。
        它促进了 Kubernetes 网络服务和服务中所有 pod 的负载平衡。
        它处理单个主机子网并确保服务可供外部各方使用。