第六章 kubernetes 组件、资源对象

一、Master 组件

---

• API server

1、提供集群管理的 REST API 接口，包括认证授权、数据校验以及集群状态变更等提供其他模块之间的数据交互和通信的枢纽（其他模块通过 API Server 查询或修改数据，只有 API Server 才直接操作 etcd）。维护的REST对象持久化到Etcd中存储。
2、通常通过 kubectl 来访问 apiserver，也可以通过 Kubernetes 各个语言的 client 库来访问 apiserver。

• etcd

1、 etcd 用于 Kubernetes 的后端存储。所有集群数据都存储在此处,始终为您的 Kubernetes 集群的 etcd 数据提供备份计划。
2、 通过api server与etcd联系得知如何访问组件，包括创建好的RC，里面有几个Pod，有几个copy，每个copy的ip地址都会存放到数据库中

• kube scheduler

1、kube-scheduler 负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点（更新 Pod 的 NodeName 字段）

调度器需要充分考虑诸多的因素：

1 公平调度
2 资源高效利用
3 QoS
4 affinity 和 anti-affinity
5 数据本地化（data locality）
6 内部负载干扰（inter-workload interference）
7 deadlines

• kube controller manager

1、Node Controller管理维护Node，定期检查Node的健康状态，标识出(失效|未失效)的Node节点。
2、Replication Controller负责维护系统中每个副本控制器对象正确数量的 Pod。管理维护Replication Controller，关联Replication Controller和Pod，保证Replication Controller定义的副本数量与实际运行Pod数量一致。新版本的 Kubernetes 中建议使用 ReplicaSet（也简称为 rs）来取代ReplicationController
3、EndPoints Controller管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,当Pod发生变化时实时更新Endpoints。
4、Namespace Controller 管理维护Namespace，定期清理无效的Namespace，包括Namesapce下的API对象，比如Pod、Service等。
5、Service Account & Token Controllers为新的命名空间创建默认帐户和 API 访问令牌
6、Service Controller管理维护Service，提供负载以及服务代理。
7、DeploymentController管理维护Deployment，关联Deployment和Replication Controller，保证运行指定数量的Pod。当Deployment更新时，控制实现Replication Controller和　Pod的更新。
8、Job Controller 管理维护Job，为Jod创建一次性任务Pod，保证完成Job指定完成的任务数目
9、Pod Autoscaler Controller 　　实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行Pod的伸缩动作。

• ADDONS(插件)----> DNS

虽然其他插件并不是必需的，但所有 Kubernetes 集群都应该具有Cluster DNS，许多示例依赖于它。

Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。

Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。

二、Node 组件

---

• kubelet

每个节点上都运行一个 kubelet 服务进程，默认监听 10250 端口，接收并执行 master 发来的指令，管理 Pod 及 Pod 中的容器。每个 kubelet 进程会在 API Server 上注册节点自身信息，定期向 master 节点汇报节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源

提供如下功能:

1 挂载 Pod 所需要的数据卷(Volume)。
2 下载 Pod 的 secrets。
3 通过 Docker 运行(或通过 rkt)运行 Pod 的容器。
4 周期性的对容器生命周期进行探测。
5 如果需要，通过创建 镜像 Pod（Mirror Pod） 将 Pod 的状态报告回系
统的其余部分。
6 将节点的状态报告回系统的其余部分。

• kube-proxy

每台机器上都运行一个 kube-proxy 服务，它监听 API server 中 service 和 endpoint 的变化情况，并通过 iptables 等来为服务配置负载均衡（仅支持 TCP 和 UDP）。 通过维护主机上的网络规则并执行连接转发，实现了Kubernetes服务抽象。

kube-proxy 当前支持一下几种实现

1 userspace：最早的负载均衡方案，它在用户空间监听一个端口，所有服务通过 iptables 转发到这个端口，然后在其内部负载均衡到实际的 Pod。该方式最主要的问题是效率低，有明显的性能瓶颈。
2 iptables：目前推荐的方案，完全以 iptables 规则的方式来实现 service 负载均衡。该方式最主要的问题是在服务多的时候产生太多的 iptables 规则，非增量式更新会引入一定的时延，大规模情况下有明显的性能问题。kube-proxy只负责生成相应的Iptables规则。
3 ipvs：为解决 iptables 模式的性能问题，v1.11 新增了 ipvs 模式（v1.8 开始支持测试版，并在 v1.11 GA），采用增量式更新，并可以保证 service 更新期间连接保持不断开
4 winuserspace：同 userspace，但仅工作在 windows 节点上

iptables模式图

• docker

Docker 用于运行容器 ----》点击参考docker命令

• supervisord

supervisord 是一个轻量级的进程监控系统，可以用来保证 kubelet 和 docker 运行。

• fluentd

fluentd 是一个守护进程，它有助于提供集群层面日志 集群层面的日志。

---

三、资源对象

• Autoscaling

Horizontal Pod Autoscaling (HPA) 可以根据 CPU 使用率或应用自定义 metrics 自动扩展 Pod 数量（支持 replication controller、deployment 和 replica set ）。

• Deployment

Deployment为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。

• Namespace

Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pod, service, replication controller 和 deployment 等都是属于某一个 namespace 的（默认是 default），而 node, persistent volume，namespace 等资源则不属于任何 namespace。

• ReplicaSet

ReplicationController（也简称为 rc）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也会自动回收。ReplicationController 的典型应用场景包括确保健康 Pod 的数量、弹性伸缩、滚动升级以及应用多版本发布跟踪等。在新版本的 Kubernetes 中建议使用 ReplicaSet（也简称为 rs）来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。虽然也 ReplicaSet 可以独立使用，但建议使用 Deployment 来自动管理 ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如 ReplicaSet 不支持 rolling-update 但 Deployment 支持），并且还支持版本记录、回滚、暂停升级等高级特性。Deployment 的详细介绍和使用方法见 这里。

• Secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。

• Volume

我们知道默认情况下容器的数据都是非持久化的，在容器消亡以后数据也跟着丢失，所以 Docker 提供了 Volume 机制以便将数据持久化存储。类似的，Kubernetes 提供了更强大的 Volume 机制和丰富的插件，解决了容器数据持久化和容器间共享数据的问题。与 Docker 不同，Kubernetes Volume 的生命周期与 Pod 绑定,容器挂掉后 Kubelet 再次重启容器时，Volume 的数据依然还在,而 Pod 删除时，Volume 才会清理。数据是否丢失取决于具体的 Volume 类型，比如 emptyDir 的数据会丢失，而 PV 的数据则不会丢

• Service

Kubernetes 在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了 Service 资源，并通过 kube-proxy 配合 cloud provider 来适应不同的应用场景。随着 kubernetes 用户的激增，用户场景的不断丰富，又产生了一些新的负载均衡机制。目前，kubernetes 中的负载均衡大致可以分为以下几种机制，每种机制都有其特定的应用场景：

主要有四种

1 Service：直接用 Service 提供 cluster 内部的负载均衡，并借助 cloud provider 提供的 LB 提供外部访问
2 Ingress Controller：还是用 Service 提供 cluster 内部的负载均衡，但是通过自定义 Ingress Controller 提供外部访问
3 Service Load Balancer：把 load balancer 直接跑在容器中，实现 Bare Metal 的 Service Load Balancer
4 Custom Load Balancer：自定义负载均衡，并替代 kube-proxy，一般在物理部署 Kubernetes 时使用，方便接入公司已有的外部服务

• StatefulSet

StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计）

其应用场景包括

1稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
2 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
3 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依序进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
4 有序收缩，有序删除（即从 N-1 到 0）

• PersistentVolume

PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 提供了方便的持久化卷：PV 提供网络存储资源，而 PVC 请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建 PVC 来将 Pod 跟数据卷关联起来。PV 和 PVC 可以将 pod 和数据卷解耦，pod 不需要知道确切的文件系统或者支持它的持久化引擎。

• DaemonSet

DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：
日志收集，比如 fluentd，logstash 等
系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

k8s参考网址 1

k8s参考网址 2