Kubernetes 架构介绍
上图可见，kubernetes的节点角色分为 master 和 node, node 节点是真正工作的节点，master 负责资源调度，所有的操作均通过 master 端的 kube-apiserver 实现，kube-apiserver 就是Kubernetes的牛鼻子。
1. Kubernetes 组件简介
1.1 Master 端
The Kubernetes Master is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: kube-apiserver, kube-controller-manager and kube-scheduler.
1.1.1 kube-apiserver
集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据的时候，则通过API Server提供的REST接口来实现，从而实现各模块这之间的信息交互。
-
与 kubelet 的交互
每个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身的状态，API Server将收到的信息放入etcd中。此外，kubelet也通过API Server的Watch接口监听Pod的信息，根据监听的变化，会相应地修改本节点Pod容器。
-
与 kube-controller-manager 交互
kube-controller-manager 中的 Node Controller 模块通过API Server提供的 watch 接口，实时监控 Node 信息，并做相应处理。
-
与 kube-scheduler 交互
通过 watch 接口监听到新建 Pod 副本信息后，它会检索所有符合该 Pod 要求的 Node 列表，开始执行 Pod 调度逻辑，调度到相应的 Node 上。
1.1.2 kube-controller-manager
Controller Manager 作为集群内的管理控制中心，负责集群内的 Node，Pod 副本，服务断点（Endpoint）, 命名空间，服务账号，资源定额等的管理，当某个 Node 意外宕机时，Controller Manager 会及时发现此故障并执行自动修复流程。
1.1.3 kube-scheduler
简单来说， 就是通过调度算法调度为待调度 Pod 列表的每个 Pod 从 Node列表中选择一个最合适的 Node。随后，kubelet 通过 API Server监听到 scheduler 产生的 Pod事件，然后获取相应的 Pod 清单，下载 image 镜像，并启动容器。
1.2 Node 端
Each individual non-master node in your cluster runs two processes: kubelet, which communicates with the Kubernetes Master. kube-proxy, a network proxy which reflects Kubernetes networking services on each node.
1.2.1 kubelet
该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器并坚持容器的健康状况。每个 kubelet 进程会在 API Server 上注册节点信息，定期向 Master 节点汇报节点资源使用情况，并通过 cAdvisor 监控容器和节点资源。
1.2.2 kube-proxy
用来转发 service 中定义的服务，默认采用 iptables 来实习转发，为了更好的性能，在 kubernetes 1.9 版本支持了 ipvs 的模式（目前还是beat版本）, 转发的流程大致如下：
client -> [service cluster_ip] -> kube-proxy -> [get pod_ip:pod_port from kube-api] -> pod
2. Kubernetes 中管理的资源
Kubernetes 作为目前最流行的一个容器调度管理平台， 它所管理的资源对象均是通过 kube-apiserver 所创建管理，下面我们就来看一看里面所管理的资源。
2.1 Pod
Pod是Kubernetes创建或部署的最小单位，一个Pod中可以包含一个或多个容器，如果是多个容器，这些容器是共享Pod中的一个网络和存储资源的。比方说，我将一个front应用容器与一个backend应用容器部署在同一个Pod中，front应用可以直接通过localhost:backend_port的形式调用backend服务，因为它们共用一个网络，外部访问就通过pod_ip:front_port。
正常情况下，我们不会通过API来直接创建Pod，而是通过后面介绍的 Deployment 来创建管理Pod，Deployment是一种声明式的，它可以声明这个Pod的状态，比如我希望这个Pod的个数是多少，kube-scheduler就会根据声明的个数尽可能地调度和实现，如果其中有Pod异常退出，它马上又会启动了一个新的。
2.2 Static Pod
Static Pod 称为静态Pod， 与 Pod 的主要区别是 Static Pod 是由 Worker Node 节点上的 kubelet 进行创建和管理的，不能通过API Server进行管理。
2.3 Replication Controller（RC）
RC是Kubernetes中的核心概念之一，简单来说，它其实是定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预设值，所以RC的定义包括如下部分：
- Pod期待的副本数（replicas）
- 用语选择目标Pod的Label Selector
- 当Pod的副本数量小于预设值，用于创建新Pod的Pod模版（template）
需要注意的是, 删除RC并不会影响通过该RC创建好的Pod，为了删除所有的Pod，可以设置replicas=0, 然后更新该RC。另外，kubectl提供了stop和delete命令来一次性删除RC和RC控制的全部Pod。
2.4 ReplicaSet
RS是上面RC的升级版本，，区别主要在于它可以使用更多的selector匹配模式，如正则，不等于等来实现目的。
2.5 Deployment
A Deployment controller provides declarative updates for Pods and ReplicaSets.
Deployment是Kubernetes1.2引入的新概念，是ReplicaSet的一个更高级的接口，它是声明式的，引入的目的是为了更好地解决Pod的编排问题。Deployment相对RC的一个最大升级是我们可以随时知道当前Pod"部署"的进度，也是官方推荐的管理Pod的方式，下面我们就通过 Deployment 来创建一个 nginx Pod。
-
创建资源文件nginx-deployment.yaml
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 -
通过 kubectl 调用API创建资源
kubectl create -f nginx-deployment.yaml -
查看运行情况
kubectl get deployments # 查看Deployment rollout status kubectl rollout status deployment/nginx-deployment # 查看 ReplicaSet kubectl get rs # 查看 Pod kubectl get pods --show-labels
滚动更新
比如，我们需要更新Pod中容器的 image tag
方法1:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
方法2 （交互式）:
kubectl edit deployment/nginx-deployment
通过 kubectl describe deployments 可以查看 rollout 日志
通过 kubectl get rs 可以查看到新建的 rs
回滚 Deployment revision
-
查看 deployment 历史
kubectl rollout history deployment/nginx-deployment # 查看具体某个版本的详情 kubectl rollout history deployment/nginx-deployment --revision=2 -
回滚
kubectl rollout undo deployment/nginx-deployment --to-revision=2
扩容 Pod
kubectl scale deployment nginx-deployment --replicas=10
2.6 DaemonSet
能够让所有（或者一些特定）的Node节点运行同一个Pod。如果删除DaemonSet，与之对应的Pod也会删除。每个Node上仅运行一次Pod副本实例。比如，日志收集agent, 监控agent等可以采用此方式运行。
2.7 Service
Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个"微服务", 定义了一个服务的访问入口。Service 通过 labels 与指定的 Pod 绑定，Service 会生成一个 Cluster IP， 我们通过这个 Cluster IP 就可以访问到Pod的资源了。
Node 节点上的 kube-proxy 进程通过 watch apiserver 中的 Pod 的变更，将与 Cluster IP 与 Pod 的规则放入 iptables 中，实现请求转发，当 Client 请求的地址是 Cluster IP就会被 iptables 中的规则匹配，根据指定的负载均衡算法，将请求转发至Pod。
2.8 Volume
Kubernetes的Volume的概念，用途和目的与Docker Volume比较类似，但两者不等价。
首先，Kubernetes中的Volume定义在Pod上，然后一个Pod里的多个容器挂载到具体的文件目录下；
其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或重启，Volume中的数据也不会丢失；
要使用卷，需要为 pod 指定为卷( spec.volumes 字段) 以及将它挂载到容器的位置( spec.containeres.volumeMounts 字段)。
Kubernetes支持多中类型的Volume，有本地的，有远程共享的，下面就例举几个常用的：
- emptyDir
当 Pod 被分配给节点时，首先创建 emptyDir 卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入 emptyDir 卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。
注意：容器崩溃不会从节点中移除 pod，因此 emptyDir 卷中的数据在容器崩溃时是安全的。
emptyDir 的用法有：
- 暂存空间，例如用于基于磁盘的合并排序
- 用作长时间计算崩溃恢复时的检查点
- Web服务器容器提供数据时，保存内容管理器容器提取的文件
示例：
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
- hostPath
hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中。该功能大多数 Pod 都用不到，但它为某些应用程序提供了一个强大的解决方法。
例如，hostPath 的用途如下：
运行需要访问 Docker 内部的容器；使用 /var/lib/docker 的 hostPath
在容器中运行 cAdvisor；使用 /dev/cgroups 的 hostPath
允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在，是否应该创建，以及它应该以什么形式存在
示例：
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional
type: Directory
