Kubernetes 之 基础概念理解

随着技术发展，运维实现部署，实现应用编排，经历了许多变化

早期，咱们可使用ansible，saltstack等批量工具进行安装，编排

后来出现了docker，应用程序容器化，编排工具也发生了变化

这里我用通俗一些的话简单介绍下早期的docker三剑客，也就是docker compose、docker swarm和docker machine的应用场景 。

docker compose

它更加适用于单机编排，换句话说，docker compose适用于一个docker host来进行编排操做

docker swarm

咱们能够理解为它能够将多个docker host整合为同一平台下管理机制的一个集群工具，通俗讲就是docker swarm能够将多个docker host提供的计算资源整合成一个资源池，随后docker compose再去编排时，只须要面向这一资源池进行编排便可，不管底层到底有什么样的docker host或是几个dockerhost。

docker machine 

docker  swarm能够将多个docker host整合，那么什么样的docker host能被它整合，知足加入docker swarm中的一个成员呢？这就须要另外一个工具，那就是docker machine，它能够将一个 docker host初始化成一个能够知足加入docker swarm集群的docker主机，咱们也能够称它为一个预处理工具。

再后来出现了咱们要讲的主角--kubernetes（k8s）

kubernetes环境架构、概念、术语

集群主机

能够说他就是一个集群，组合多台主机的资源，整合成一个大的资源池，并统一对外提供计算、存储等能力的集群，说白了就是找不少台主机，每一台主机上都安装上 kubernetes的应用程序，并经过这些应用程序协同工做，把多个主机当成一个主机来使用，让 全部主机来完成通讯 ，从而完成彼此间的协调。

    在k8s中，主机是分角色的，属于有中心节点架构的集群系统， 称为master/nodes结构模型

    一组节点用来扮演master主节点，不需太多，可以作冗余，通常三个，是整个集群的惟一入口。

    nodes在作相关的工做，能够理解为master是蜂王，用来指挥，node则为工蜂，是干活的。每个node节点，都是来贡献一部分计算能力，存储能力等相关资源的节点，说白了就是运行容器的节点。

 一个容器的启动

用户把建立启动容器的请求先发给master，master当中有一个调度器去分析各node现有的可用资源状态，而后找一个最适配的node节点利用本地的docker或者容器引擎把这个容器启动起来。

要启动这个容器须要镜像，接受这个请求的node节点先会在本地是否有镜像，若没有，这个node节点则从外部的dockerhub或私有redis，亦或者是K8S内本身的redis上把镜像拖下来，来启动所被请求的容器。

Node组件

kubelet、kube-proxy

kubelet

在每一个节点（node）上都要运行一个 worker 对容器进行生命周期的管理，这个 worker 程序就是 kubelet。简单地说，kubelet 的主要功能就是定时从某个地方获取节点上 pod/container 的指望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。

kubelet的主要做用可归纳为节点管理、pod管理、容器健康检查、容器监控

节点管理

Kubelet在建立之初就会向API Server作自注册，而后会定时报告节点的信息给API Server写入到Etcd中。默认为10秒。

pod管理

Kubelet会监听API Server，若是发现对Pod有什么操做，它就会做出相应的动做。例如发现有Pod与本Node进行了绑定。那么Kubelet就会建立相应的Pod且调用Docker Client下载image并运行container。

容器健康检查

有三种方式对容器作健康检查： 
1.在容器内部运行一个命令，若是该命令的退出状态码为0，则代表容器健康。 
2.TCP检查。 
3.HTTP检查。

容器监控

Kubelet经过cAdvisor对该节点的各种资源进行监控。若是集群须要这些监控到的资源信息，能够安装一个组件Heapster。

Heapster会进行集群级别的监控，它会经过Kubelet获取到全部节点的各类资源信息，而后经过带着关联标签的Pod分组这些信息。

若是再配合InfluxDB与Grafana，那么就成为一个完整的集群监控系统了。

kube-proxy

每一个pod上都会运行一个kube-proxy，负责接收并转发请求。Kube-proxy的核心功能是将到Service的访问请求转发到后台的某个具体的Pod。(service是一组pod的服务抽象，至关于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，通常称为cluster IP)具体来讲，就是实现了内部从pod到service和外部的从node port向service的访问。

举个例子，如今有podA，podB，podC和serviceAB。serviceAB是podA，podB的服务抽象(service)。那么kube-proxy的做用就是能够将pod(不论是podA，podB或者podC)向serviceAB的请求，进行转发到service所表明的一个具体pod(podA或者podB)上。请求的分配方法通常分配是采用轮询方法进行分配。

另外，kubernetes还提供了一种在node节点上暴露一个端口，从而提供从外部访问service的方式。

不管是经过ClusterIP+Port的方式仍是NodeIP+NodePort的方式访问Service，最终都会被节点的Iptables规则重定向到Kube-proxy监听服务代理端口，当Kube-proxy监听到Service的访问请求后，它会找到最适合的Endpoints，而后将请求转发过去。具体的路由选择依据Round Robin算法及Service的Session会话保持这两个特性。

Master包含三个组件。

controller-manager，scheduler，apiserver，他们的状态和信息都保存在etcd中，因此etcd也要作冗余

API server

kubernetes把master之上的一个组件称为API server，负责接收请求，解析请求，处理请求，它提供了HTTP Rest接口的关键服务进程，是kubernetes里全部资源的增删改查等操做的惟一入口，也是集群的入口进程。

调度器-scheduler

若是客户端请求建立一个容器，这个容器不该该是建立在master之上的，而应该是node之上，可是哪个node更合适？此时就引出另外一个概念，那就是调度器，叫作scheduler，负责去观测每个可用的node之上总共可用的计算资源和存储资源，并根据用户所请求建立的容器所须要的最低需求量、资源量去评估，哪个节点更合适，所以kubernetes设计了一个两级调度的方式来完成调度，第一步，先作预选，即先初步评估一下到底有多少个适合启动请求容器需求的节点，第二步，从筛选出的node中挑选出最佳适配，取决于你的调度算法中的优选算法来决定

控制器管理器-controller-manager

kubernetes还拥有自愈能力。当其中一台node节点上的容器故障了，它会在其余合适的节点上建立一台相同的容器来，确保这个容器始终是健康的。那么咱们如何知道他是否故障呢？---持续监控它，因此kubernetes还实现了一大堆的叫控制器的组件，它会在本地不停的loop循环，持续性的负责去监控他所管理的容器是不是健康的，一旦发现问题，控制器就会向master APIserver发请求说个人容器挂了一个，你在帮我调度一个适配的node把容器启动起来。

可是，当咱们以前说的去负责持续监控的scheduler控制器出现问题了，又该如何解决呢？这就引出了master之上的另外一重要组件，控制器管理器-controller-manager，他是kubernetes里全部资源对象的自动化管理中心，能够理解为资源对象的“大总管”，它负责去监控着每个控制器是健康的。

node节点可动态增长到kubernetes集群中，前提是这个节点已经正确安装、配置和启动了上述的关键进程，默认状况下，kubelet会向master注册本身，这也是kubernetes推荐的node管理方式，一旦node被归入集群管理范围，kubelet会定时向master汇报自身的状况，以及以前有哪些pod在运行等，这样master能够获知每一个node的资源使用状况，并实现高效均衡的资源调度策略。若是node没有按时上报信息，则会被master判断为失恋，node状态会被标记为not ready，随后master会触发工做负载转移流程。

Pod

是kubernetes最重要也是最基本的概念，每一个Pod都会包含一个‘根容器’，还会包含一个或者多个紧密相连的业务容器，pod是kubernetes中最基本的管理单位，而不是 container。

flannel

kubernetes为每一个Pod都分配了惟一的IP地址，称之为PodIP，一个Pod里的多个容器共享PodIP地址，要求底层网络支持集群内任意两个Pod之间的直接通讯，一般采用虚拟二层网络技术来实现（Flannel）

Label

是一个key=value的键值对，其中key与value由用户本身指定。能够附加到各类资源对象上，一个资源对象能够定义任意数量的Label。能够经过LabelSelector（标签选择器）查询和筛选资源对象

Etcd  

Etcd一种k-v存储仓库，可用于服务发现程序。在Kubernetes中就是用Etcd来存储各类k-v对象的。 

Etcd是Kubernetes的一个重要组件。当咱们不管是建立Deployment也好，仍是建立Service也好，各类资源对象信息都是写在Etcd中了。

各个组件是经过API Server进行交流的，然而数据的来源是Etcd。因此维持Etcd的高可用是相当重要的。若是Etcd坏了，任何程序也没法正常运行了。

总结

Kubernetes的这些组件各自分别有着重要的功能。它们之间协同工做，共同保证了Kubernetes对于容器化应用的自动管理。

API Server起着桥梁的做用，各个组件都要经过它进行交互。Controller Manager像是集群的大管家，管理着许多事务。Scheduler就像是一个调度亭，负责Pod的调度工做。

Kubelet则在每一个节点上都有，像是一个执行者，真正建立、修改、销毁Pod的工做都是由它来具体执行。

Kube-proxy像是负载均衡器，在外界须要对Pod进行访问时它做为代理进行路由工做，将具体的访问分给某一具体的Pod实例。

Etcd则是Kubernetes的数据中心，用来存储Kubernetes建立的各种资源对象信息。

这些组件缺一不可，不管少了哪个Kubernetes都不能进行正常的工做。这里大概讲了下各组件的功能，感兴趣的能够分析Kubernetes的源码，github中就有。