Kubernetes

一、Kubernetes介绍

Kubernetes

1.1、应用部署方式演变

在部署应用程序的方式上，主要经历了三个时代：

●传统部署：互联网早期，会直接将应用程序部署在物理机上

优点：简单，不需要其它技术的参与
​
缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响

●虚拟化部署：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境

优点：程序环境不会相互产生影响，提供了一定程度的安全性
​
缺点：增加了操作系统，浪费了部分资源

●容器化部署：与虚拟化类似，但是共享了操作系统

优点：
​
可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
​
运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦
​
容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

容器化部署方式给带来很多的便利，但是也会出现一些问题，比如说：

●一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器

●当并发访问量变大的时候，怎么样做到横向扩展容器数量

这些容器管理的问题统称为容器编排问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：

Swarm：Docker自己的容器编排工具

Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用

Kubernetes：Google开源的的容器编排工具

1.2、kubernetes简介

K8S,是Google开源的容器集群管理系统，在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态仲缩等一 系列完整功能，提高了大规模容器集群管理的便捷性。 其主要功能如下：

●使用Docker 等容器技术对应用程序包装( package) 、实例化(instantiate) 、运行(run) 。

●以集群的方式运行、管理跨机器的容器。以集群的方式运行、管理跨机器的容器。

●解决Docker.跨机器容器之间的通讯问题。解决Docker跨机器容器之间的通讯问题。

●K8S的自我修复机制使得容器集群总是运行在用户期望的状态。

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

●自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器

●弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整

●服务发现：服务可以通过自动发现的形式找到它所依赖的服务

●负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡

●版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本

●存储编排：可以根据容器自身的需求自动创建存储卷

1.3、kubernetes组件

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策 ( 管理 )

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
​
Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
​
ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
这些控制器主要包括:
  ●NodeController(节点控制器):负责在节点出现故障时发现和响应。
  ●Replication dontroller (副本控制器) :负责保证集群中一个RC (资源对象        Replication Controller) 所关联的Pod副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量
  ●Endpoints Controller ( 端点控制器) :填充端点对象(即连接Services 和Pods) ，负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的endpoint。
  ●Service Account & Token Controllers (服务帐户和令牌控制器) :为新的命名空间创建默认帐户和API访问令牌。
  ●ResourceQuotaController(资源配额控制器):确保指定的资源对象在任何时候都不会超量占用系统物理资源。
  ●Namespace Controller (命名空间控制器) :管理namespace的生命周期。
  ●Service Controller (服务控制器) :属于K8S集群与外部的云平台之间的一-个接口控制器。
​
Etcd ：配置存储中心，负责存储集群中各种资源对象的信息

node：集群的数据平面，负责为容器提供运行环境 ( 干活 )

Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
​
KubeProxy : 负责提供集群内部的服务发现和负载均衡
​
Docker : 负责节点上容器的各种操作

下面，以部署一个nginx服务来说明kubernetes系统各个组件调用关系：

1、首先要明确，一旦kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中

2、一个nginx服务的安装请求会首先被发送到master节点的apiServer组件

3、apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上。在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer

4、apiServer调用controller-manager去调度Node节点安装nginx服务

5、kubelet接收到指令后，会通知docker，然后由docker来启动一个nginx的pod，

pod是kubernetes的最小操作单元，容器必须跑在pod中至此，

6、一个nginx服务就运行了，如果需要访问nginx，就需要通过kube-proxy来对pod产生访问的代理

这样，外界用户就可以访问集群中的nginx服务了

1.4、kubernetes概念

 

Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控

Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行

Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器

Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

• • Deployment：无状态应用部署。Deployment 的作用是管理和控制 Pod 和 ReplicaSet，管控它们运行在用户期望的状态中。

  • Replicaset：确保预期的 Pod 副本数量。ReplicaSet 的作用就是管理和控制 Pod，管控它们好好干活。但是，ReplicaSet 受控于 Deployment。

    • 可以理解为 Deployment 就是总包工头，主要负责监督底下的工人 Pod 干活，确保每时每刻都有用户要求数量的 Pod 在工作，如果一旦发现了某个工人 Pod 不行了，就赶紧新拉一个 Pod 过来替换它。而ReplicaSet就是包工头手底下的小包工头。 从 K8S 使用者角度来看，用户只需要关系Deployment 而不操心 ReplicaSet 的前身，官方推荐用 Deployment 取代 Replication Controller 来部署服务。

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

• Statefulset：有状态应用部署。

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

• Cronjob：周期性计划任务。

Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签

Service：pod对外服务的统一入口，下面可以维护同一类的多个pod， Service 是一组提供相同服务的 Pod 的对外访问接口、流量均衡器。

Ingress

• Service 主要负责K8S集群内部的网络拓扑，那么集群外部怎么访问集群内部呢?这个时候就需要Ingress了。Ingress 是整个 K8S 集群的接入层，负责集群内外通讯。

• Ingress是K8S集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口，典型的访问方式是http/https。Service只能进行第四层的流量调度，表现形式是ip+port。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。

Name

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

NameSpace：命名空间，用来隔离pod的运行环境

客户端创建pod 流程：

用户管理员创建 Pod 的请求通过kubectl 客户端管理命令将请求发送给 API Server。

API Server会对请求作相应的处理并将处理的结果存入存储系统 Etcd 中。

API Server组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上。在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer

apiServer调用controller-manager去调度Node节点安装pod

kubelet接收到指令后，会通知docker，然后由docker来安装pod，创建好pod之后，Kubelet会收集pod运行状态和使用情况返回给APIserver并写入到etcd数据库中，同时controller-manager也会去关注pod运行状态，一旦pod数量没要达到预设的期望值controller-manager还会通过上面的流程去创建pod，直到符合预期副本数目。

当用户访问时 ，通过kube-proxy来对pod产生访问的代理