Kubernetes笔记（二）：了解k8s的基本组件与概念

前文 Kubernetes笔记（一）：十分钟部署一套K8s环境介绍了如何快速搭建一个k8s系统。为了继续使用k8s来部署我们的应用，需要先对k8s中的一些基本组件与概念有个了解。

Kubernetes是什么

Kubernetes是Google于2014年基于其内部Brog系统开源的一个容器编排管理系统，可使用声明式的配置（以yaml文件的形式）自动地执行容器化应用程序的管理，包括部署、伸缩、负载均衡、回滚等。

kubernetes提供的功能：

自动发布与伸缩：可以通过声明式的配置文件定义想要部署的容器，Kubernetes将自动进行容器的部署，达到期望的结果；通过指定容器副本数，或者设置根据资源负载情况（如CPU、内存使用率），自动对容器组进行快速的伸缩——增大或缩小容器数量
滚动升级与灰度发布：采用逐步替换的策略实现滚动升级，使用Kubernetes也可以很轻易地管理系统的灰度发布
服务发现与负载均衡：Kubernetes通过DNS名称或IP地址暴露容器的访问方式，并且可在同一容器组内实现负载分发与均衡
存储编排：Kubernetes可以自动挂载指定的存储系统，如local storage/nfs/云存储等
故障恢复：Kubernetes自动重启已经停机的容器，替换不满足健康检查的容器
密钥与配置管理：Kubernetes可以存储与管理敏感信息，如Docker Registry的登录凭证，密码，ssh密钥等

Kubernetes架构

我们先来看一张Kubernetes的架构图

Kubernetes是一套分布式系统，与大多数分布式系统类似，包含控制节点（master node）与工作节点（worker node）。

master node

控制节点就是指挥官，负责发号施令的，其上运行一些管理服务来对整个系统进行管理与控制，包括

apiserver：作为整个系统的对外接口，提供一套Restful API供客户端调用，任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行,如kubectl、kubernetes dashboard等管理工具就是通过apiserver来实现对集群的管理
kube-scheduler：资源调度器，负责将容器组分配到哪些节点上
kube-controller-manager：管理控制器，集群中处理常规任务的后台线程，包括节点控制器（负责监听节点停机的事件并作出对应响应）、endpoint-controller（刷新服务与容器组的关联信息）、replication-controller（维护容器组的副本数为指定的数值）、Service Account & Token控制器（负责为新的命名空间创建默认的 Service Account 以及 API Access Token）
etcd：数据存储，存储集群所有的配置信息
coredns：实现集群内部通过服务名称进行容器组访问的功能

worker node

工作节点就是具体干活的小兵，其上也运行一些服务来执行指挥官分派的任务，包括

kubelet：是工作节点上执行操作的代理程序，负责容器的生命周期管理，定期执行容器健康检查，并上报容器的运行状态
kube-proxy：是一个具有负载均衡能力的简单的网络访问代理，负责将访问某个服务的请求分配到工作节点的具体某个容器上（kube-proxy也运行于master node上）
Docker Daemon：这个不难理解，所有服务或容器组都要以Docker容器的形式来运行（但Kubernetes其实不局限于Docker，它支持任何实现了Kubernetes容器引擎接口的容器引擎，如containerd、rktlet）

另外还有既在master node上也在worker node上运行的网络通信组件 kube-flannel。这些服务组件一般运行在kube-system的命名空间中，如图

Kubernetes基本概念

我们再来看第二张图

功能组件在上面已经做了介绍。Kubernetes的操作对象主要包括容器组（Pod），服务（Service），副本控制器（replication-controller），及围绕这些的其它辅助对象

Pod

Pod是Kubernetes创建或部署的最小基本单元。一个Pod封装一个或多个应用容器、存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod中的每个容器共享网络命名空间（包括IP与端口），Pod内的容器可以使用localhost相互通信。Pod可以指定一组共享存储卷Volumes，Pod中所有容器都可以访问共享的Volumes，Volumes用于数据持久化，防止容器重启丢失数据。

Volume

Kubernetes使用Volume来解决Pod中容器重启数据丢失的问题，以及Pod中多个容器间数据共享的问题。Kubernetes支持的Volume类型包括：

emptyDir：当Pod分配到Node上时，将会创建emptyDir，只要Node上的Pod一直运行，Volume就会一直存在。当Pod（不管任何原因）从Node上被删除时，emptyDir也同时会删除，存储的数据也将永久删除，但删除容器不影响emptyDir
hostPath：hostPath允许挂载Node上的文件系统到Pod里面去。如果Pod需要使用Node上的文件，可以使用hostPath
nfs: 使用nfs网络文件系统提供的共享目录

ReplicationController

ReplicationController确保在任何时候都有按配置的Pod副本数在运行。现在推荐使用配置ReplicaSet（下一代ReplicationController）的Deployment来建立副本管理机制。

ReplicaSet

ReplicaSet是下一代ReplicationController，两者的唯一区别是ReplicaSet支持新的基于集合的选择器，而ReplicationController仅支持基于相等选择器的需求。

Deployment

Deployment为Pod与ReplicaSet提供了声明式的定义，描述你想要的目标状态是什么，Deployment controller就会帮你将Pod与ReplicaSet的实际状态改变到你想要的目标状态。

Service

一个Service可以看做一组提供相同服务的Pod的对外访问接口。Kubernetes提供两种类型的Service：

NodePort：集群外部可以通过Node IP与Node Port来访问具体某个Pod
ClusterIP：指通过集群的内部IP暴露服务，服务只能够在集群内部可以访问，这也是默认的 ServiceType

Label

Label就是一对key/value，可以附加到各种资源对象上，如Node、Pod、Service等，一个资源对象可以定义任意数量的Label。可以通过Label选择器来选择具备某个（些）Label的资源。

PV & PVC

PersistentVolume（PV）为用户提供了一个存储抽象，由管理员设置，它是集群的一部分。就像节点是集群中的资源一样，PV也是集群中的资源。 PV是Volume之类的卷插件，但具有独立于Pod的生命周期。

PersistentVolumeClaim（PVC）是用户存储的请求。它与Pod相似。Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。PVC可以请求特定大小和访问模式的存储资源（例如，可以以读/写或只读模式挂载）。

Secret

Secret解决了密码、token、密钥等敏感数据的存储问题，Secret的三种类型：

Service Account ：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
Opaque ：Base64编码格式的Secret，用来存储密码、密钥等
kubernetes.io/dockerconfigjson ：用来存储docker registry的认证信息

ConfigMap

ConfigMap用来保存key/value对的配置数据，这个数据可以在Pods里使用，或者被用来为像controller一样的系统组件存储配置数据。ConfigMap可以方便的处理不含敏感信息的字符串（敏感信息可使用Secret）。

Namespace

Namespace类似于Kubernetes中的虚拟集群，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。比如我们如果开发测试共用一个Kubernetes集群，则可以将开发环境的服务部署到dev的namespace，测试环境的部署到test的namespace。

Ingress

为集群服务提供外部访问，包括基于Nginx与Traefik两个版本，为服务提供域名绑定访问与路径路由功能。也可以基于Ingress实现服务的灰度发布。

总结

本文对Kubernetes中涉及的基本组件与概念进行了整理，对其基本构成有了一个大致的理解与印象。下一篇将从一个实践出发，实现一个基于Gitlab+Jenkins+K8s的CI/CD流程，以对涉及的各个组件进行深入了解与学习。