k8s基础-简介、优缺点及相关资料

Kubernetes简称k8s。是谷歌Borg的开源的容器编排、调度和管理平台。

弹性伸缩、滚动升级、健康检查

kube-apiserver： 资源增删改查等操作的入口，也是集群控制的入口。
kube-controller-manager： 资源对象的自动化控制。
kube-scheduler： 资源调度。

kubelet：负责pod对应的容器创建和启停，与master节点协作，实现集群管理。以systemd服务方式运行。
kube-proxy：实现service的通信与负载均衡。该模块实现了服务发现和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP连接转发，默认基于Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面：kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护service到endpoint的映射关系，从而保证后端pod的IP变化不会对访问者造成影响。另外，kube-proxy还支持session affinity。
docker：docker引擎，负责本机的容器创建和管理。

Pod抽象基于linux的namespace和cgroups，为容器提供隔离的环境。
pod运行在节点（node）中，每个pod都有一个pause特殊容器，其状态代表整个容器组的状态。其他的是业务容器，业务容器共享pause容器的网络栈和volume挂载卷，因此业务容器间的通信和数据交换更高效，解决了容器组的文件共享问题。
k8s要求底层网络支持集群内任意两个pod之间的tcp直接通信，这是通过虚拟二层网络技术实现。
node中有pod，pod中有pause容器和业务容器。node可以是虚拟机也可以是物理机。

创建pod过程：kubectl --> deployment --> replicaset --> pod
当k8s把pod调度到节点上，节点上的kubelet会指示docker启动容器。接着，kubelet会通过cgroup持续收集容器的信息，再提交到k8s的管理。
随着CRI标准的成熟，k8s逐渐弱化docker的作用。rkt等也符合CRI标准。

Kubernetes通过Label机制进行对象的弱关联，可以灵活地进行分类和选择。基于label可实现多维度的资源分组管理。实现集群的高可用。
有两种label selector表达式：基于等式的（=，！=）和基于集合的（in， not in）。多个表达式之间用“,”进行分割，是and的关系。
新的管理对象如deployment、replicaset、daemonset和job都可以在selector中使用基于集合的筛选条件定义，matchLabels，可用的条件运算符包括in、notin、exists、doesnotexists。
label具有严格的命名规则，定义的是k8s对象的元数据，并且用于label selector。
label selector在Kubernetes中多重要使用场景有以下几处:

1.kube-controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现Pod副本的数量始终符合预期设定。
2.kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
3.通过对Node定义特定的Label，并且在Pod定义文件中使用NodeSelector标签调度策略，kube-scheduler进程可以实现Pod“定向调度”的特性。

annotation是用户任意定义的“附加”信息，方便外部工具进行查找。

deployment是从v1.2引入，为了更好解决pod的编排问题。
deployment使用rs来实现目的。deployment相对于rc的最大优点是随时知道当前pod"部署"的进度。

k8s不会直接创建pod，而是通过controller来管理pod。有以下几类controller：

replicaSet，实现pod的多副本管理。使用deployment时会自动创建replicaSet，即deployment通过replicaSet管理pod的多个副本，因此通常不需要直接使用replicaSet。
daemonSet，节点中最多运行一个pod副本。
statefulSet，保证pod副本在整个生命周期中名称不变。也保证副本按固定的顺序启动、更新或者删除。
job，用于运行结束就删除的应用。

rc定义期望场景，即声明某种pod的副本数量在任意时刻符合某个预期值。通过rc，实现用户应用集群的高可用。删除rc并不会影响通过该rc已创建好的pod。
在k8s v1.2时，rc升级为replica set，rs与rc的唯一区别是：rs支持基于集合的label selector，而rc只支持基于等式的label selector。
rs主要被deployment这个更高层的资源对象所使用，从而形成一整套pod创建、删除、更新的编排机制。rs与deployment将逐步替换rc，是k8s v1.3里pod自动扩容、缩容的基础。

通过追踪分析rc控制的所有目标pod的负载变化情况，来确定是否需要针对性地调整目标pod的副本数，这是HPA的实现原理。HPA有两种方式作为pod负载的度量指标：

CPUUtilizationPercentage，需要安装Heapster。
应用程序自定义的度量指标，比如TPS或QPS。

pod管理对象rc、deployment、daemonSet和job都是面向无状态的服务。
k8s在v1.4引入petset，在v1.5更名为statefulSet。statefulSet特性如下：

statefulSet中的pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。
statefulSet中的pod副本的启停顺序是受控的。
statefulSet中的pod采用稳定的持久化存储卷。
statefulSet需与headless service配合使用，headless service与普通的service的关键区别在于，它没有cluster ip。如果解析headless service的dns域名，则返回的是该service对应的全部pod的endpoint列表。

用于实现多租户的资源隔离。容器的隔离功能利用的是linux内核的namespace机制。

重建部署、滚动更新部署、影子部署、蓝绿部署、金丝雀部署、A/B测试。

CSI是k8s从v1.9版本开始引入的，用于在容器和共享存储之间建立标准的存储访问接口。在CSI之前，k8s集群通过“in-tree”方式提供共享存储服务，这种方式要求存储供应商的代码集成到k8s的代码中。

k8s默认健康检查机制：容器启动时执行由dockerFile的CMD或ENTRYPOINT指定的进程。如果进程退出时返回码非零，则认为容器发生故障，然后根据restartPolicy重启容器。

liveness探测，判断是否重启容器。
readiness探测，判断容器是否已经准备好对外服务，不是则将容器设置为不可用，不接收service转发的请求。
两钟探测可同时使用。
health check 可用于scale up和roll update 。

olume，volume定义在pod上，被pod里的多个容器挂载到具体的文件目录下。volume与pod的生命周期相同，而与容器的生命周期无关。类似于目录。
persistentVolume（PV），可理解为k8s集群中的某个网络存储对应的一块存储。生命周期独立于pod。
persistentVolumeClaim（PVC），对PV的申请。
动态供给，通过storageClass实现，storageClass定义了如何创建PV。

secret以密文方式存储数据，以volume形式挂载到pod。容器通过卷的方式使用secret中的数据，也可以通过环境变量的方式使用这些数据。
configMap用于保存非敏感数据

helm帮助用户在k8s上高效的运行和管理微服务架构应用。helm由客户端（管理chart）和tiller服务器(管理release)组成。
chart是helm的应用打包格式，由一组文件和目录构成。其中最重要的是模板，模板中定义了k8s各类资源的配置信息，helm在部署时用values.yaml中的参数值注入到模板中，生成标准的YAML配置文件。
helm采用go语言的模板编写chart。

从三个级别进行管理：

container：CPU和内存，资源请求和资源限制。
pod：limitRange。
namespace：resourceQuota。
cpu的资源单位是CPU（Core）的数量，是绝对值。通常以千分之一的CPU配额为最小单位，用m表示。memory配额，是绝对值，单位是内存字节数。

weave scope是docker和k8s可视化监控工具。
heapster是k8s原生的集群监控方案。以pod的形式运行。
promotheus operator是基于prometheus的k8s监控方案。除可监控node和pod外，还可监控api server、scheduler、controller manager等。

新版本的k8s开始基于ipvs来替换iptables。