一、 K8s 是什么？

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。

二、为什么使用K8s？

使用Kubernetes可以：

1. 自动化容器的部署和复制 
2. 随时扩展或收缩容器规模 
3. 将容器组织成组，并且提供容器间的负载均衡 
4. 很容易地升级应用程序容器的新版本 
4. 提供容器弹性，如果容器失效就替换它，等等…

三、Kubernetes解决的问题：

1. 调度 - 容器应该在哪个机器上运行 
2. 生命周期和健康状况 - 容器在无错的条件下运行 
3. 服务发现 - 容器在哪，怎样与它通信 
4. 监控 - 容器是否运行正常 
5. 认证 - 谁能访问容器 
6. 容器聚合 - 如何将多个容器合并成一个工程

四、执行流程是什么样的？

通过Kubectl提交一个创建RC的请求，该请求通过APIServer被写入etcd中，此时Controller Manager通过
API Server的监听资源变化的接口监听到这个RC事件，分析之后，发现当前集群中还没有它所对应的Pod实例，
于是根据RC里的Pod模板定义生成一个Pod对象，通过APIServer写入etcd，接下来，此事件被Scheduler发现，
它立即执行一个复杂的调度流程，为这个新Pod选定一个落户的Node，然后通过API Server讲这一结果写入到etcd中，
随后，目标Node上运行的Kubelet进程通过APIServer监测到这个“新生的”Pod，并按照它的定义，启动该Pod并
任劳任怨地负责它的下半生，直到Pod的生命结束。随后，我们通过Kubectl提交一个新的映射到该Pod的
Service的创建请求，ControllerManager会通过Label标签查询到相关联的Pod实例，然后生成Service的
Endpoints信息，并通过APIServer写入到etcd中，接下来，所有Node上运行的Proxy进程通过APIServer查询并监听
Service对象与其对应的Endpoints信息，建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能。


Master

Master节点上面主要由四个模块组成：APIServer、scheduler、controller manager、etcd。

APIServer: APIServer负责对外提供RESTful的Kubernetes API服务，
它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给
APIServer处理后再提交给etcd。如架构图中所示，kubectl（Kubernetes提供的客户端工具，
该工具内部就是对Kubernetes API的调用）是直接和APIServer交互的。

schedule: scheduler的职责很明确，就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子，
那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定，即将这个pod部署到这个Node上。
Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。
controller manager: 如果说APIServer做的是“前台”的工作的话，那controller manager就是负责“后台”的。
每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的。比如我们通过APIServer
创建一个pod，当这个pod创建成功后，APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样
的重任就由controller manager去保证了。

etcd: etcd是一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。

Node

每个Node节点主要由三个模块组成：kubelet、kube-proxy、runtime。

runtime。runtime指的是容器运行环境，目前Kubernetes支持docker和rkt两种容器。

kube-proxy。该模块实现了Kubernetes中的服务发现和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP连接转发，默认基于Round
Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面，
kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，
从而保证了后端pod的IP变化不会对访问者造成影响。另外kube-proxy还支持session affinity。

kubelet。Kubelet是Master在每个Node节点上面的agent，是Node节点上面最重要的模块，它负责维护和管理该Node上面的所有容器，
但是如果容器不是通过Kubernetes创建的，它并不会管理。本质上，它负责使Pod得运行状态与期望的状态一致。

至此，Kubernetes的Master和Node就简单介绍完了。下面我们来看Kubernetes中的各种资源/对象。

五、上面说的一堆名词，那么他们到底是什么？

1、Pod是什么东西？

Pod是Kubernetes的最基本操作单元，包含一个或多个紧密相关的容器，类似于豌豆荚的概念。一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”（Logical Host）。一个Pod中的多个容器应用通常是紧耦合的。Pod在Node上被创建、启动或者销毁。为什么Kubernetes使用Pod在容器之上再封装一层呢？一个很重要的原因是，Docker容器之间的通信受到Docker网络机制的限制。在Docker的世界中，一个容器需要link方式才能访问另一个容器提供的服务（端口）。大量容器之间的link将是一个非常繁重的工作。通过Pod的概念将多个容器组合在一个虚拟的“主机”内，可以实现容器之间仅需要通过Localhost就能相互通信了。

2、 一个Pod中的应用容器共享同一组资源（Pod内的容器是不会跨宿主机的），如下所述：

PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID；
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围；
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或者POSIX消息队列进行通信；
UTS命名空间：Pod中的多个容器共享一个主机名；
Volumes（共享存储卷）：Pod中的各个容器可以访问在Pod级别定义的Volumes。

3、 对Pod的定义

对Pod的定义通过Yaml或Json格式的配置文件来完成。下面的配置文件将定义一个名为redis-slave的Pod，其中kind为Pod。在spec中主要包含了Containers（容器）的定义，可以定义多个容器。

apiVersion: v1  #指定api版本，此值必须在kubectl apiversion中  
kind: Pod       #指定创建资源的角色/类型，如Pod， Deployment, Service等等
metadata:       #资源的元数据/属性 
  name: redis-slave  #资源的名字，在同一个namespace中必须唯一 
  labels:   #设定资源的标签 详情http://blog.csdn.net/liyingke112/article/details/77482384
    name: redis-slave
  annotations:            #自定义注解列表  
    - name: String        #自定义注解名字  
spec: #指定该资源的内容
  restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器  
  nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1  
    zone: node1  
  containers:
  - name: slave   #容器的名字  
    image: kubeguide/guestbook-redis-slave  #容器使用的镜像地址
    imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registry）images的策略，
                           # Always，每次都检查
                           # Never，每次都不检查（不管本地是否有）
                           # IfNotPresent，如果本地有就不检查，如果没有就拉取
    command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT  
    args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数 
  env:  #指定容器中的环境变量
  - name: GET_HOSTS_FROM  #变量的名字
    value: env   #变量的值
  resources: #资源管理，请求请见http://blog.csdn.net/liyingke112/article/details/77452630
  requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行  
    cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
    memory: 32Mi #内存使用量  
  limits: #资源限制  
    cpu: 0.5  
    memory: 32Mi  
  ports:
    - containerPort: 6379  #容器开放对外的端口
      name: redis  #名称
      protocol: TCP  

下面是一个httpd更详细的例子

apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中  
kind: Pod #指定创建资源的角色/类型  
metadata: #资源的元数据/属性  
  name: web04-pod #资源的名字，在同一个namespace中必须唯一  
  labels: #设定资源的标签，详情请见http://blog.csdn.net/liyingke112/article/details/77482384
    k8s-app: apache  
    version: v1  
    kubernetes.io/cluster-service: "true"  
  annotations:            #自定义注解列表  
    - name: String        #自定义注解名字  
spec:#specification of the resource content 指定该资源的内容  
  restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器  
  nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1  
    zone: node1  
  containers:  
  - name: web04-pod #容器的名字  
    image: web:apache #容器使用的镜像地址  
    imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，
                           # Always，每次都检查
                           # Never，每次都不检查（不管本地是否有）
                           # IfNotPresent，如果本地有就不检查，如果没有就拉取
    command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT  
    args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数  
    env: #指定容器中的环境变量  
    - name: str #变量的名字  
      value: "/etc/run.sh" #变量的值  
    resources: #资源管理，请求请见http://blog.csdn.net/liyingke112/article/details/77452630
      requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行  
        cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
        memory: 32Mi #内存使用量  
      limits: #资源限制  
        cpu: 0.5  
        memory: 32Mi  
    ports:  
    - containerPort: 80 #容器开发对外的端口
      name: httpd  #名称
      protocol: TCP  
    livenessProbe: #pod内容器健康检查的设置，详情请见http://blog.csdn.net/liyingke112/article/details/77531584
      httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常  
        path: / #URI地址  
        port: 80  
        #host: 127.0.0.1 #主机地址  
        scheme: HTTP  
      initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始  
      timeoutSeconds: 5 #检测的超时时间  
      periodSeconds: 15  #检查间隔时间  
      #也可以用这种方法  
      #exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常  
      #  command:  
      #    - cat  
      #    - /tmp/health  
      #也可以用这种方法  
      #tcpSocket: //通过tcpSocket检查健康   
      #  port: number   
    lifecycle: #生命周期管理  
      postStart: #容器运行之前运行的任务  
        exec:  
          command:  
            - 'sh'  
            - 'yum upgrade -y'  
      preStop:#容器关闭之前运行的任务  
        exec:  
          command: ['service httpd stop']  
    volumeMounts:  #详情请见http://blog.csdn.net/liyingke112/article/details/76577520
    - name: volume #挂载设备的名字，与volumes[*].name 需要对应，如下面定义的    
      mountPath: /data #挂载到容器的某个路径下  
      readOnly: True  
  volumes: #定义一组挂载设备  
  - name: volume #定义一个挂载设备的名字  
    #meptyDir: {}  
    hostPath:  
      path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种

4、定义完成后可以使用

创建
kubectl create -f podfile 
查看  
kubectl get pod yourPodName
kubectl describe pod yourPodName
删除
kubectl delete pod yourPodName
更新
kubectl replace /path/to/yourNewYaml.yaml

5、Pod的生命周期

• Replication Controller（RC）是Kubernetes中的另一个核心概念，应用托管在Kubernetes之后，Kubernetes需要保证应用能够持续运行，这是RC的工作内容，它会确保任何时间Kubernetes中都有指定数量的Pod在运行。在此基础上，RC还提供了一些更高级的特性，比如滚动升级、升级回滚等。
• Pod的生命周期过程包括：通过模板进行定义，然后分配到一个Node上运行，就不会离开这个Node，直到被删除。当某个Pod失败，首先会被Kubernetes清理掉，之后ReplicationController将会在其它机器上（或本机）重建Pod，重建之后Pod的ID发生了变化，那将会是一个新的Pod。所以，Kubernetes中Pod的迁移，实际指的是在新Node上重建Pod。
  在整个过程中，Pod处于一下4种状态之一：

Pending：Pod定义正确，提交到Master，但其所包含的容器镜像还未完成创建。通常Master对Pod进行调度需要一些时间，之后Node对镜像进行下载也需要一些时间；
Running：Pod已被分配到某个Node上，且其包含的所有容器镜像都已经创建完成，并成功运行起来；
Succeeded：Pod中所有容器都成功结束，并且不会被重启，这是Pod的一种最终状态；
Failed：Pod中所有容器都结束了，但至少一个容器是以失败状态结束的，这也是Pod的一种最终状态。

• RC与Pod的关联——Label

RC与Pod的关联是通过Label来实现的。Label机制是Kubernetes中的一个重要设计，通过Label进行对象的弱关联，可以灵活地进行分类和选择。对于Pod，需要设置其自身的Label来进行标识，Label是一系列的Key/value对，在Pod-->metadata-->labeks中进行设置。

Label的定义是任一的，但是Label必须具有可标识性，比如设置Pod的应用名称和版本号等。另外Lable是不具有唯一性的，为了更准确的标识一个Pod，应该为Pod设置多个维度的label。如下：

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

举例，当你在RC的yaml文件中定义了该RC的selector中的label为app:my-web，那么这个RC就会去关注Pod-->metadata-->labeks中label为app:my-web的Pod。修改了对应Pod的Label，就会使Pod脱离RC的控制。同样，在RC运行正常的时候，若试图继续创建同样Label的Pod，是创建不出来的。因为RC认为副本数已经正常了，再多起的话会被RC删掉的。

• 弹性伸缩

弹性伸缩是指适应负载变化，以弹性可伸缩的方式提供资源。反映到Kubernetes中，指的是可根据负载的高低动态调整Pod的副本数量。调整Pod的副本数是通过修改RC中Pod的副本是来实现的，示例命令如下：

扩容Pod的副本数目到10

$ kubectl scale relicationcontroller yourRcName --replicas=10

缩容Pod的副本数目到1

$ kubectl scale relicationcontroller yourRcName --replicas=1

• 滚动升级

滚动升级是一种平滑过渡的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始升级的时候就可以及时发现、调整问题，以保证问题影响度不会扩大。Kubernetes中滚动升级的命令如下：

$ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s

升级开始后，首先依据提供的定义文件创建V2版本的RC，然后每隔10s（--update-period=10s）逐步的增加V2版本的Pod副本数，逐步减少V1版本Pod的副本数。升级完成之后，删除V1版本的RC，保留V2版本的RC，及实现滚动升级。

升级过程中，发生了错误中途退出时，可以选择继续升级。Kubernetes能够智能的判断升级中断之前的状态，然后紧接着继续执行升级。当然，也可以进行回退，命令如下：

$ kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s --rollback

回退的方式实际就是升级的逆操作，逐步增加V1.0版本Pod的副本数，逐步减少V2版本Pod的副本数。

• 新一代副本控制器replica set

这里所说的replica set，可以被认为 是“升级版”的Replication Controller。也就是说。replica set也是用于保证与label selector匹配的pod数量维持在期望状态。区别在于，replica set引入了对基于子集的selector查询条件，而Replication Controller仅支持基于值相等的selector条件查询。这是目前从用户角度肴，两者唯一的显著差异。 社区引入这一API的初衷是用于取代vl中的Replication Controller，也就是说．当v1版本被废弃时，Replication Controller就完成了它的历史使命，而由replica set来接管其工作。虽然replica set可以被单独使用，但是目前它多被Deployment用于进行pod的创建、更新与删除。Deployment在滚动更新等方面提供了很多非常有用的功能，关于DeplOymCn的更多信息，读者们可以在后续小节中获得。

• Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。另外，不建议在Kubernetes的一个Pod内运行相同应用的多个实例。

5.1、Pod之间的通信：同一个Node内。

• 通过Veth连接在同一个docker0网桥上，它们的IP地址都是从docker0的网桥上动态获取的，它们和网桥本身的IP3是同一个网络段的。

5.2、不同Node上的Pod之间的通信。

• 对docker0的IP地址做统一的规划；对Pod的IP地址做统一的规划；

5.3、Pod到Service之间的通信。

• Service的虚拟IP通过每个Node上的kube-proxy映射到不同的Pod上，暂时只支持轮询。

5.4、外部到内部的访问

• NodePort、LoadBalancer、Ingress三种方式。

5.5 、nodePort

• nodePort

外部机器可访问的端口。

比如一个Web应用需要被其他用户访问，那么需要配置`type=NodePort`，而且配置`nodePort=30001`，那么其他机器就可以通过浏览器访问`scheme://node:30001`访问到该服务，例如`http://node:30001`。
例如MySQL数据库可能不需要被外界访问，只需被内部服务访问，那么不必设置NodePort

• targetPort

容器的端口（最根本的端口入口），与制作容器时暴露的端口一致（DockerFile中EXPOSE），例如docker.io官方的nginx暴露的是80端口。

• port

kubernetes中的服务之间访问的端口，尽管mysql容器暴露了3306端口，但是集群内其他容器需要通过33306端口访问该服务，外部机器不能访问mysql服务，因为他没有配置NodePort类型

• 举例

# web
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 type: NodePort
 ports:
 - port: 30080
   targetPort: 80
   nodePort: 30001
 selector:
  name: nginx-pod

# mysql
apiVersion: v1
kind: Service
metadata:
 name: mysql-service
spec:
 ports:
 - port: 33306
   targetPort: 3306
 selector:
  name: mysql-pod

5.6. LoadBalancer

如果云服务商支持外接负载均衡器，则可以通过spec.type=LoadBalaner定义Service，同时需要制定负载均衡器的IP地址。使用这种类型需要指定Service的nodePort和clusterIP。例如：

apiVersion: v1
kind: Service
metadata: {
  "kind" "Service",
  "apiVersion": "v1",
  "metadata": {
    "name": "my-service"
  },
  "spec": {
    "type": "LoadBalaner",
    "clusterIP": "10.0.171.239",
    "selector": {
    "app": "MyApp"
    },
  "ports": [
     {
      "protocol": "TCP",
      "port": 80,
      "targetPort": 9376,
      "nodePort": 30061
     }
    ],
  },
   "status": {
      "loadBalancer": {
          "ingress": [
             {
               "ip": "146.148.47.155"
             }
           ]
        }
    }
  }

在这个例子中，status.loadBalancer.ingress.ip设置的146.146.47.155为云服务商提供的负载均衡器的IP地址。

之后，对该Service的访问请求将会通过LoadBalancer转发到后端Pod上去，负载分发的实现方式则依赖于云服务上提供的LoadBalancer的实现机制。

六、Node 概念

Node通常是物理机、虚拟机或者云服务商提供的资源，并不是由Kubernetes创建的。我们说Kubernetes创建一个Node，仅仅表示Kubernetes在系统内部创建了一个Node对象，创建后即会对其进行一系列健康检查，包括是否可以连通、服务是否正确启动、是否可以创建Pod等。如果检查未能通过，则该Node将会在集群中被标记为不可用（Not Ready）。

七、Label 概念

Label机制是K8S中一个重要设计，通过Label进行对象弱关联，灵活地分类和选择不同服务或业务，让用户根据自己特定的组织结构以松耦合方式进行服务部署。

Label是一对KV，对用户而言非常有意义的，但对K8S本身而言没有直接意义的。Label可以在创建对象时指定，也可以在后期修改，每个对象可以拥有多个标签，但key值必须是唯一的。

Label可随意定义，但建议可读性，比如设置Pod的应用名称和版本号等。另外Lable是不具有唯一性的，为了更准确标识资源对象，应为资源对象设置多维度的label。如下：

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

语法和字符集

Label keys的语法

一个可选前缀+名称，通过/来区分

名称部分是必须的，并且最多63个字符，开始和结束的字符必须是字母或者数字，中间是字母数字和_、-、.。

前缀可选，如指定必须是个DNS子域，一系列的DNS label通过.来划分，长度不超过253个字符，“/”来结尾。如前缀被省略了，这个Label的key被假定为对用户私有的。系统组成部分（比如scheduler,controller-manager,apiserver,kubectl）,必须要指定一个前缀，Kuberentes.io前缀是为K8S内核部分保留的。
label value语法

长度不超过63个字符。

可以为空

首位字符必须为字母数字字符

中间必须是横线、_、.、数字、字母。
Label选择器

label选择器（selector）是K8S中核心的组织原语，通过label选择器，客户端能方便辨识和选择一组资源对象。API目前支持两种选择器：基于相等的和基于集合的,在使用时可以将多个Label进行组合来选择。

使用基于相等的选择器时，选择器的所有键值和其他资源对象的label键值完全相同（包括数量，key和value），才能匹配。

name = redis-slave: 选择所有包含Label中key="name"且value="redis-slave"的对象；
env != production: 选择所有包括Label中的key="env"且value不等于"production"的对象。

而使用基于集合的label选择器，只要选择器部分键值匹配其他资源对象的label，就算匹配。选择器可以由一个以上条件（KV键值）组成，在多个条件的情况下，所有条件都必须满足。

name in (redis-master, redis-slave): 选择所有包含Label中的key="name"且value="redis-master"或"redis-slave"的对象；
name not in (php-frontend): 选择所有包含Label中的key="name"且value不等于"php-frontend"的对象。

在某些对象需要对另一些对象进行选择时，可以将多个Label Selector进行组合，使用逗号","进行分隔即可。基于等式的LabelSelector和基于集合的Label Selector可以任意组合。例如：

name=redis-slave,env!=production
name not in (php-frontend),env!=production

更新资源类型的Label

Label作为用户可灵活定义的对象属性，在已创建的对象上，仍然可以随时通过kubectl label命令对其进行增加、修改、删除等操作。 例如，我们要给已创建的Pod“redis-master-bobr0”添加一个标签role=backend：

kubectl label pod redis-master-bobr0 role=backend
kubectl get pods -L role
    NAME                 READY     STATUS    RESTARTS   AGE       ROLE
    redis-master-bobr0   1/1       Running   0          3m        backend

删除一个Label，只需在命令行最后指定Label的key名并与一个减号相连即可：

kubectl label pod redis-master-bobr0 role-

修改一个Label的值，需要加上--overwrite参数：

kubectl label pod redis-master-bobr0 role=master –overwrite

八、Service（服务）

在Kubernetes的世界里，虽然每个Pod都会被分配一个单独的IP地址，这个IP地址会随时Pod的销毁而消失。这就引出一个问题：如果有一组Pod组成一个集群来提供服务，那么如何来访问它们呢？

Kubernetes的Service（服务）就是用来解决这个问题的核心概念。

一个Service可以看作一组提供相同服务的Pod的对外访问接口。Service作用于哪些Pod是通过Label Selector来定义的。

8.1. 对Service的定义

对Service的定义同样使用Yaml或Json格式的配置文件来完成。以redis-slave服务的定义为例：

apiVersion: v1
kind: Service
metadata:
  name: redis-slave
  labels:
    name: redis-slave
spec:
  ports:
  - port: 6379
  selector:
    name: redis-slave

通过该定义，Kubernetes将会创建一个名为"redis-slave"的服务，并在6379端口上监听。spec.selector的定义表示该Service将包含所有具有"name=redis-slave"的Label的Pod。

在Pod正常启动后，系统将会根据Service的定义创建出与Pod对应的Endpoint（端点）对象，以建立起Service与后端Pod的对应关系。随着Pod的创建、销毁，Endpoint对象也将被更新。Endpoint对象主要有Pod的IP地址和容器所需监听的端口号组成。

8.2. Pod的IP地址和Service的Cluster IP地址

Pod的IP地址是Docker Daemon根据docker0网桥的IP地址段进行分配的，但Service的Cluster IP地址是Kubernetes系统中的虚拟IP地址，由系统动态分配。Service的Cluster IP地址相对于Pod的IP地址来说相对稳定，Service被创建时即被分配一个IP地址，在销毁该Service之前，这个IP地址都不会再变化了。而Pod在Kubernetes集群中生命周期较短，可能被ReplicationContrller销毁、再次创建，新创建的Pod将会分配一个新的IP地址。

8.3. 外部访问Service

由于Service对象在Cluster IP Range池中分配到的IP只能在内部访问，所以其他Pod都可以无障碍地访问到它。如果这个Service作为前端服务，准备为集群外的客户端提供服务，我们就需要给这个服务提供公共IP了。

Kubernetes支持对外提供服务的Service的type定义：NodePort和LoadBalancer（见上文）和另外的Ingress

• Ingress，是一种HTTP方式的路由转发机制，由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API，实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer、HaProxy、Nginx等开源方案。。

8.4 service 自发现机制

Kubernetes中有一个很重要的服务自发现特性。一旦一个service被创建，该service的service IP和service port等信息都可以被注入到pod中供它们使用。Kubernetes主要支持两种service发现 机制：环境变量和DNS。
环境变量方式

Kubernetes创建Pod时会自动添加所有可用的service环境变量到该Pod中，如有需要．这些环境变量就被注入Pod内的容器里。需要注意的是，环境变量的注入只发送在Pod创建时，且不会被自动更新。这个特点暗含了service和访问该service的Pod的创建时间的先后顺序，即任何想要访问service的pod都需要在service已经存在后创建，否则与service相关的环境变量就无法注入该Pod的容器中，这样先创建的容器就无法发现后创建的service。
DNS方式

Kubernetes集群现在支持增加一个可选的组件——DNS服务器。这个DNS服务器使用Kubernetes的watchAPI，不间断的监测新的service的创建并为每个service新建一个DNS记录。如果DNS在整个集群范围内都可用，那么所有的Pod都能够自动解析service的域名。

8.5 多个service如何避免地址和端口冲突

此处设计思想是，Kubernetes通过为每个service分配一个唯一的ClusterIP，所以当使用ClusterIP：port的组合访问一个service的时候，不管port是什么，这个组合是一定不会发生重复的。另一方面，kube-proxy为每个service真正打开的是一个绝对不会重复的随机端口，用户在service描述文件中指定的访问端口会被映射到这个随机端口上。这就是为什么用户可以在创建service时随意指定访问端口。

8.6 service目前存在的不足

Kubernetes使用iptables和kube-proxy解析service的人口地址，在中小规模的集群中运行良好，但是当service的数量超过一定规模时，仍然有一些小问题。首当其冲的便是service环境变量泛滥，以及service与使用service的pod两者创建时间先后的制约关系。目前来看，很多使用者在使用Kubernetes时往往会开发一套自己的Router组件来替代service，以便更好地掌控和定制这部分功能。

九、Deployment

Kubernetes提供了一种更加简单的更新RC和Pod的机制，叫做Deployment。通过在Deployment中描述你所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成你所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：

• 有Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。
• 事件和状态查看：可以查看Deployment的升级详细进度和状态。
• 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
• 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
• 暂停和启动：对于每一次升级，都能够随时暂停和启动。
• 多种升级方案：Recreate----删除所有已存在的pod,重新创建新的; RollingUpdate----滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。

9.1 滚动升级Deployment

相比于RC，Deployment直接使用kubectl edit deployment/deploymentName 或者kubectl set方法就可以直接升级（原理是Pod的template发生变化，例如更新label、更新镜像版本等操作会触发Deployment的滚动升级）。操作示例——首先 我们同样定义一个nginx-deploy-v1.yaml的文件，副本数量为2：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

创建deployment：

$ kubectl create -f nginx-deploy-v1.yaml --record
deployment "nginx-deployment" created
$ kubectl get deployments
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s
$ kubectl get deployments
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           18s

正常之后，将nginx的版本进行升级，从1.7升级到1.9。第一种方法，直接set镜像：

$ kubectl set image deployment/nginx-deployment2 nginx=nginx:1.9
deployment "nginx-deployment2" image updated

第二种方法，直接edit：

$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment2" edited

查看Deployment的变更信息（以下信息得以保存，是创建时候加的“--record”这个选项起的作用）：

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION    CHANGE-CAUSE
1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

最后介绍下Deployment的一些基础命令。

$ kubectl describe deployments  #查询详细信息，获取升级进度
$ kubectl rollout pause deployment/nginx-deployment2  #暂停升级
$ kubectl rollout resume deployment/nginx-deployment2  #继续升级
$ kubectl rollout undo deployment/nginx-deployment2  #升级回滚
$ kubectl scale deployment nginx-deployment --replicas 10  #弹性伸缩Pod数量

关于多重升级，举例，当你创建了一个nginx1.7的Deployment，要求副本数量为5之后，Deployment Controller会逐步的将5个1.7的Pod启动起来；当启动到3个的时候，你又发出更新Deployment中Nginx到1.9的命令；这时Deployment Controller会立即将已启动的3个1.7Pod杀掉，然后逐步启动1.9的Pod。Deployment Controller不会等到1.7的Pod都启动完成之后，再依次杀掉1.7，启动1.9。

十、Volume

在Docker的设计实现中，容器中的数据是临时的，即当容器被销毁时，其中的数据将会丢失。如果需要持久化数据，需要使用Docker数据卷挂载宿主机上的文件或者目录到容器中。在Kubernetes中，当Pod重建的时候，数据是会丢失的，Kubernetes也是通过数据卷挂载来提供Pod数据的持久化的。Kubernetes数据卷是对Docker数据卷的扩展，Kubernetes数据卷是Pod级别的，可以用来实现Pod中容器的文件共享。目前，Kubernetes支持的数据卷类型如下：

1) EmptyDir
2) HostPath
3) GCE Persistent Disk
4) AWS Elastic Block Store
5) NFS
6) iSCSI
7) Flocker
8) GlusterFS
9) RBD
10) Git Repo
11) Secret
12) Persistent Volume Claim
13) Downward API

10.1 本地数据卷

EmptyDir、HostPath这两种类型的数据卷，只能最用于本地文件系统。本地数据卷中的数据只会存在于一台机器上，所以当Pod发生迁移的时候，数据便会丢失。该类型Volume的用途是：Pod中容器间的文件共享、共享宿主机的文件系统。

10.1.1 EmptyDir

如果Pod配置了EmptyDir数据卷，在Pod的生命周期内都会存在，当Pod被分配到 Node上的时候，会在Node上创建EmptyDir数据卷，并挂载到Pod的容器中。只要Pod 存在，EmptyDir数据卷都会存在（容器删除不会导致EmptyDir数据卷丟失数据），但是如果Pod的生命周期终结（Pod被删除），EmptyDir数据卷也会被删除，并且永久丢失。

EmptyDir数据卷非常适合实现Pod中容器的文件共享。Pod的设计提供了一个很好的容器组合的模型，容器之间各司其职，通过共享文件目录来完成交互，比如可以通过一个专职日志收集容器，在每个Pod中和业务容器中进行组合，来完成日志的收集和汇总。

10.1.2 HostPath

HostPath数据卷允许将容器宿主机上的文件系统挂载到Pod中。如果Pod需要使用宿主机上的某些文件，可以使用HostPath。

10.2 网络数据卷

Kubernetes提供了很多类型的数据卷以集成第三方的存储系统，包括一些非常流行的分布式文件系统，也有在IaaS平台上提供的存储支持，这些存储系统都是分布式的，通过网络共享文件系统，因此我们称这一类数据卷为网络数据卷。

网络数据卷能够满足数据的持久化需求，Pod通过配置使用网络数据卷，每次Pod创建的时候都会将存储系统的远端文件目录挂载到容器中，数据卷中的数据将被水久保存，即使Pod被删除，只是除去挂载数据卷，数据卷中的数据仍然保存在存储系统中，且当新的Pod被创建的时候，仍是挂载同样的数据卷。网络数据卷包含以下几种：NFS、iSCISI、GlusterFS、RBD（Ceph Block Device）、Flocker、AWS Elastic Block Store、GCE Persistent Disk 7.3 Persistent Volume和Persistent Volume Claim

理解每个存储系统是一件复杂的事情，特别是对于普通用户来说，有时候并不需要关心各种存储实现，只希望能够安全可靠地存储数据。Kubernetes中提供了Persistent Volume和Persistent Volume Claim机制，这是存储消费模式。Persistent Volume是由系统管理员配置创建的一个数据卷（目前支持HostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、iSCSI、GlusterFS、RBD），它代表了某一类存储插件实现；而对于普通用户来说，通过Persistent Volume Claim可请求并获得合适的Persistent Volume，而无须感知后端的存储实现。Persistent Volume和Persistent Volume Claim的关系其实类似于Pod和Node，Pod消费Node资源，Persistent Volume Claim则消费Persistent Volume资源。Persistent Volume和Persistent Volume Claim相互关联，有着完整的生命周期管理：

1) 准备：系统管理员规划或创建一批Persistent Volume；
2) 绑定：用户通过创建Persistent Volume Claim来声明存储请求，Kubernetes发现有存储请求的时候，就去查找符合条件的Persistent Volume（最小满足策略）。找到合适的就绑定上，找不到就一直处于等待状态；
3) 使用：创建Pod的时候使用Persistent Volume Claim；
4) 释放：当用户删除绑定在Persistent Volume上的Persistent Volume Claim时，Persistent Volume进入释放状态，此时Persistent Volume中还残留着上一个Persistent Volume Claim的数据，状态还不可用；
5) 回收：是否的Persistent Volume需要回收才能再次使用。回收策略可以是人工的也可以是Kubernetes自动进行清理（仅支持NFS和HostPath）
7.4信息数据卷
Kubernetes中有一些数据卷，主要用来给容器传递配置信息，我们称之为信息数据卷，比如Secret（处理敏感配置信息，密码、Token等）、Downward API（通过环境变量的方式告诉容器Pod的信息）、Git Repo（将Git仓库下载到Pod中），都是将Pod的信息以文件形式保存，然后以数据卷方式挂载到容器中，容器通过读取文件获取相应的信息。

十一、Pet Sets/StatefulSet

K8s在1.3版本里发布了Alpha版的PetSet功能。在云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改。PetSet中Pod的名字的作用，是用来关联与该Pod对应的状态。

对于RC和RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状态，Pod像牲畜一样没有分别；对于PetSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂在上原来Pod的存储继续以它的状态提供服务。

适合于PetSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务。PetSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。使用PetSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。

十二、ConfigMap

很多生产环境中的应用程序配置较为复杂，可能需要多个config文件、命令行参数和环境变量的组合。并且，这些配置信息应该从应用程序镜像中解耦出来，以保证镜像的可移植性以及配置信息不被泄露。社区引入ConfigMap这个API资源提供了将配置数据注入容器的方式来满足这一需求。
　　ConfigMap包含了一系列的键值对，用于存储被Pod或者系统组件（如controller）访问的信息。这与secret的设计理念有异曲同工之妙，它们的主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。

十三、Horizontal Pod Autoscaler

自动扩展作为一个长久的议题，一直为人们津津乐道。系统能够根据负载的变化对计算资源的分配进行自动的扩增或者收缩，无疑是一个非常吸引人的特征，它能够最大可能地减少费用或者其他代价（如电力损耗）。自动扩展主要分为两种，其一为水平扩展，针对于实例数目的增减；其二为垂直扩展，即单个实例可以使用的资源的增减。Horizontal Pod Autoscaler（HPA）属于前者。

13.1 Horizontal Pod Autoscaler如何工作

• Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或Deployment对应的Pod，根据观察到的CPU实际使用量与用户的期望值进行比对，做出是否需要增减实例数量的决策。controller目前使用heapSter来检测CPU使用量，检测周期默认是30秒。

13.2 Horizontal Pod Autoscaler的决策策略

• 在HPA Controller检测到CPU的实际使用量之后，会求出当前的CPU使用率（实际使用量与pod 请求量的比率)。然后，HPA Controller会通过调整副本数量使得CPU使用率尽量向期望值靠近．另外，考虑到自动扩展的决策可能需要一段时间才会生效，甚至在短时间内会引入一些噪声． 例如当pod所需要的CPU负荷过大，从而运行一个新的pod进行分流，在创建的过程中，系统的CPU使用量可能会有一个攀升的过程。所以，在每一次作出决策后的一段时间内，将不再进行扩展决策。对于ScaleUp而言，这个时间段为3分钟，Scaledown为5分钟。再者HPA Controller允许一定范围内的CPU使用量的不稳定，也就是说，只有当aVg（CurrentPodConsumption／Target低于0.9或者高于1.1时才进行实例调整，这也是出于维护系统稳定性的考虑。

十四、 Namespace（命名空间）

Namespace（命名空间）是Kubernetes系统中的另一个非常重要的概念，通过将系统内部的对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。
Kubernetes集群在启动后，会创建一个名为“default”的Namespace，通过Kubectl可以查看到。
使用Namespace来组织Kubernetes的各种对象，可以实现对用户的分组，即“多租户”管理。对不同的租户还可以进行单独的资源配额设置和管理，使得整个集群的资源配置非常灵活、方便。

十五、Annotation（注解）

Annotation与Label类似，也使用key/value键值对的形式进行定义。Label具有严格的命名规则，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector。Annotation则是用户任意定义的“附加”信息，以便于外部工具进行查找。
用Annotation来记录的信息包括：

• build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像hash值、docker registry地址等；
• 日志库、监控库、分析库等资源库的地址信息；
• 程序调试工具信息，例如工具名称、版本号等；
• 团队的联系信息，例如电话号码、负责人名称、网址等。