Kubernetes的资源控制器和Service(四)

一、定义和分类

1，定义

　　k8s 中内建了很多控制器（controller ），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。

2，类型

　　ReplicationController、ReplicaSet、DaemonSet、StatefulSet、Job/CronJob和Horizontal Pod Autoscaling

二、资源控制器的定义和示例

1，ReplicationController 和 ReplicaSet

　　ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代，而如果异常多出来的容器也会被自动回收。

　　在新版本的k8s中建议使用ReplicaSet(RS)来取代RC，RS与RC没有本质的不同，只是名字不一样，并且RS支持集合式的selector，即通过标签(labels)来管理多个Pod。

RS示例：(rs.yaml)

apiVersion: extensions/v1beta1
kind: ReplicaSet  #类型为RS
metadata:
  name: rs-1 #RS的名称
spec:
  replicas: 3  #Pod的副本数
  selector: #选择器
    matchLabels:
      tier: frontend #需要匹配的Pod标签
  template: #定义Pod
    metadata:
      labels:
        tier: frontend #当前Pod的标签
    spec:
      containers:
      - name: nginx-container
        image: hub.xcc.com/my/mynginx:v1
        ports:
        - containerPort: 80

执行如下命令:

kubectl create -f rs.yaml
#获取rs
kubectl get rs
#列出指定标签
kubectl get pod --show-labels -l tier=frontend
#修改标签为frontend1
kubectl label pod rs-1-abc tier=frontend1 --overwrite=true
#查看pod
kubectl get pod --show-labels
#删除控制器rs-1
kubectl delete rs rs-1
kubectl get pod --show-labels

2，Deployment

　　Deployment为Pod和RS提供了一个声明式定义方法，用来替换以前的RC来方便的管理应用。

Deployment示例:(deployment.yaml)

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deployment-1 #名称
spec:
  replicas: 3 #Pod副本
  template:
    metadata:
      labels:
        app: nginx-app #Pod标签
    spec:
      containers:
      - name: nginx-container
        image: hub.xcc.com/my/mynginx:v1
        ports:
        - containerPort: 80

创建查看命令

#创建并保存记录
kubectl apply -f demployment.yaml --record
#查看Deployment
kubectl get deployment
#查看rs
kubectl get rs
#查看Pod 显示标签
kubectl get pod --show-labels

扩容

# 将Pod的期望副本数扩容到5个
kubectl scale deployment deployment-1 --replicas 5
kubectl get pod --show-labels

滚动更新

[root@master01 ~]# kubectl set image deployment/deployment-1 nginx-container=hub.xcc.com/library/mynginx:v2
deployment.extensions/deployment-1 image updated

# 查看 deployment，发现没什么变化
[root@master01 ~]# kubectl get deployment
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
deployment-1   5/5     5            5           24m

# 查看 rs，出现了一个新的rs，pod数量维持在5个，并且原先的rs的pod数量变为0了
# deployment-1-6fd64dcb5 就是deployment升级后新创建的rs，并且Pod里的容器使用的是新的镜像
[root@master01 ~]# kubectl get rs
NAME                      DESIRED   CURRENT   READY   AGE
deployment-1-6fd64dcb5    5         5         5       22s
deployment-1-7796b9c74d   0         0         0       22m

#查看更新状态
[root@master01 ~]# kubectl rollout status deployment/deployment-1
deployment "deployment-1" successfully rolled out

#查看升级记录
[root@k8s-master01 ~]# kubectl rollout history deployment/deployment-1
deployment.extensions/deployment-1
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=demployment.yaml --record=true
2         kubectl apply --filename=demployment.yaml --record=true

#查看单个revision 的详细信息
kubectl rollout history deployment/deployment-1 --revision=2

清理 Policy

　　设置 Deployment 中的 .spec.revisionHistoryLimit 项来指定保留多少旧的 ReplicaSet。 余下的将在后台被当作垃圾收集。默认的，所有的 revision 历史就都会被保留。

　　注意： 将该值设置为0，将导致所有的 Deployment 历史记录都会被清除，该 Deployment 就无法再回退了。

回滚更新

#回退到上一个版本
kubectl rollout undo deployment/deployment-1
#回退到指定版本 首先查看版本记录
kubectl rollout history deployment/deployment-1
#再回退到指定版本为2
kubectl rollout undo deployment/deployment-1 --to-revision=2

更新策略

　　Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）。

　　Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）。

　　在未来的 Kuberentes 版本中，将从1-1变成25%-25%。

Rollover（多个rollout并行）

　　假如您创建了一个有5个 niginx:1.7.9 replica 的 Deployment，但是当还只有3个 nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有5个 nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的 Pod 都创建完成后才开始改变航道。

3，DaemonSet

　　DaemonSet确保全部（或者一些）node 上运行一个 Pod 的副本。当有新的 node 加入集群时，会自动为他们添加一个这样的 Pod。当有集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它所创建的所有 Pod。

使用场景

• 运行集群存储 daemon，例如在每个 node 上运行 glusterd、ceph。
• 在每个 node 上运行日期收集 daemon，例如 fluentd、logstash。
• 在每个 node 上运行监控 daemon，例如 Prometheus node Exporter、collectd、Datadog 代理或New Relic 代理。

DaemonSet 示例：(daemonset.yaml)

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: daemonset-1 #名称
  labels:
    app: daemonset-app #daemonSet标签
spec:
  selector:
    matchLabels:
      name: daemonset-label #选择指定的Pod
  template:
    metadata:
      labels:
        name: daemonset-label #定义Pod的标签
    spec:
      containers:
      - name: nginx-container
        image: hub.xcc.com/my/mynginx:v1
        ports:
        - containerPort: 80

执行命令

kubectl create -f daemonset.yaml
#查看daemonSet
kubectl get ds
#查看Pod标签
kubectl get pod --show-labels
#查看Pod运行的节点
kubectl get pod -o wide

　　DaemonSet 确保了集群中每一个节点都会运行一个 Pod（master 节点没有运行是因为污点的设置）。就算我们删除某个节点的 Pod，DaemonSet 也会马上为这个节点重新创建一个 Pod。当然此时如果有新的节点加入到集群中，那么 DaemonSet 也会为这个新节点自动创建一个这样的 Pod。

4，Job

　　Job 负责批处理任务，即仅执行一次的任务，它能够确保批处理任务的一个或多个 Pod 运行成功。意思就是，运行一个 Job 来创建 Pod，让里面的容器成功运行了指定的次数，才认为这个 Job 是成功的，那么这个 Job 才算执行完成。

特殊说明

• spec.template 格式同 Pod
• restartPolicy 策略仅支持 Never 或 OnFailure。
• 单个 Pod 时，默认 Pod 成功运行后 Job 即结束。
• .spec.completions 标志 Job 结束需要成功运行的 Pod 个数，默认为 1。
• .spec.parallelism 标志并行运行的 Pod 个数，默认为 1。
• spec.activeDeadlineSeconds 标志失败的重试最大时间，超过这个时间不会继续重试。

Job示例:(job.yaml)

apiVersion: batch/v1
kind: Job
metadata:
  name: job-1 #job名称
spec:
  template:
    metadata:
      name: job-app
    spec:
      containers:
      - name: busybox-container
        image: hub.xcc.com/my/mybusybox:v1
        command: ['sh', '-c', 'echo hello world']
      restartPolicy: Never

执行命令

kubectl create -f job.yaml
kubectl get job
kubectl get pod
#查看日志
kubectl log job-1-abcd1

5，CronJob

　　CronJob 管理基于时间的 Job，即：

• 在给定的时间点运行一次
• 周期性的在给定时间点运行
• 其本质就是在特定的时间循环创建 Job 来执行任务
• 其表达式为：分、时、日、月、周

常用场景：

• 在给定的时间点调度 Job 运行
• 创建周期性的运行的 Job，例如：数据库备份，发送邮件。

CronJob 的示例：(cronjob.yaml)

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-1
spec:
  schedule: "*/1 * * * *"  #spec.schedule：调度，必须字段，指定任务运行周期，格式为分、时、日、月、周。
  jobTemplate: #spec.jobTemplate：Job 模板，必须字段，指定需要运行的任务，格式同 Job。
    spec:
      template:
        metadata:
          name: cronjob-app
        spec:
          containers:
          - name: busybox-container
            image: hub.xcc.com/my-xcc/my-busybox:v1
            command: ['sh', '-c', 'date && echo hello world']
          restartPolicy: Never
#spec.startingDeadlineSeconds：启动 Job 的期限（秒级别），该字段是可选的，如果因为任何原因而错过了被调度的时间，那么错过指定时间的 Job 将被认为的失败的。默认无期限。

执行命令

kubectl apply -f cronjob.yaml
kubectl get cj
#查看job，每分钟执行一个job
kubectl get job
kubectl get pod
#查看pod日志
kubectl log cronjob-1-15123460-acdf6

6，StatefulSet

　　StatefulSet 为 Pod 提供唯一的标识，它可以保证部署和 scale 的顺序。StatefulSet 是为了解决有状态服努的问题，对应 Deployment 和 ReplicaSet 是为无状态服务而设计。

　　StatefulSet 有以下特点：

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

7，HPA(Horizontal Pod Autoscaling)

　　应用的资源使用率通常都有高峰和低谷的时候，如何削峰埋谷，提高集群的整体资源利用率，让 service 中的 Pod 个数自动调整昵？这就有赖于 Horizontal Pod Autoscaling 了，顾名思义，使 Pod 水平自动缩放。

三、Service

1，定义

　　k8s 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。Service是k8s中的一个重要概念，主要是提供负载均衡和服务自动发现。

2，Service的类型

• ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP。普通Service：通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP）；Headless Service：DNS会将headless service的后端直接解析为podIP列表。
• NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务。
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort 。
• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

3，Service的创建

　　一个 Service 在 k8s 中是一个 Rest 对象，和 Pod 类似。 像所有的 Rest 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例。 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 "app=MyApp" 标签。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376   #将请求代理到使用 TCP 端口 9376，并且具有标签 "app=MyApp" 的 Pod 上

　　a)ClusterIP类型

　　clusterIP 主要在每个 node 节点使用 iptables 或 ipvs，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口。

　　主要需要以下几个组件的协同工作：

• apiserver：用户通过 kubectl 命令向 apiserver 发送创建 service 的命令，apiserver 接收到请求后将数据存储 到 etcd 中。
• kube-proxy：k8s 的每个节点中都有一个叫做 kube-porxy 的进程，这个进程负责感知 service，pod 的变化，并将变化的信息写入本地的 iptables 或 ipvs 规则中。
• iptables 或 ipvs：使用 NAT 等技术将 virtual IP 的流量转至 endpoints 中。

创建Deployment（cluster-deployment.yaml）

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
    namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx-container
        image: hub.xcc.com/my-xcc/my-nginx:v1
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

创建一个 Service（cluster-svc.yaml）

apiVersion: v1
kind: Service
metadata:
  name: cluster-svc
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: nginx-app
  ports:
  - name: http
    port: 80
    targetPort: 80

执行命令

#先创建deployment
kubectl apply -f cluster-deployment.yaml
kubectl get deployment
#查看pod及其对应的ip
kubectl get pod -o wide

#创建svc
kubectl apply -f cluster-svc.yaml
kubectl get svc
# 查看 ipvs规则。可以看见 svc 所在的 ip 地址代理的是上面的三个 pod 的 ip
ipvsadm -Ln

　　b)NodePort类型

　如果设置 type 的值为 "NodePort"，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定。

创建NodePort资源(nodeport-svc.yaml)

apiVersion: v1
kind: Service
metadata:
  name: nodeport-svc
  namespace: default
spec:
  type: NodePort
  selector:
    app: nginx-app
  ports:
  - name: http
    port: 80
    targetPort: 80
    # 绑定到宿主机的31234端口，如果不指定，将随机分配30000-32767
    nodePort: 31234

执行命令

kubectl apply -f nodeport-svc.yaml
kubectl get svc
# 查看 ipvs 规则
ipvsadm -Ln

　　c)LoadBalancer 类型

　　使用支持外部负载均衡器的云提供商的服务，设置 type 的值为 "LoadBalancer"，将为 Service 提供负载均衡器。 负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 Service 的 status.loadBalancer 字段被发布出去。

示例：(loadbalancer-svc.yaml)

kind: Service
apiVersion: v1
metadata:
  name: loadbalancer-svc
spec:
  selector:
    app: nginx-App
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30061
  clusterIP: 10.0.124.225
  loadBalancerIP: 79.41.36.129
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
      - ip: 124.145.67.177

　　来自外部负载均衡器的流量将直接打到 backend Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 在这些情况下，将根据用户设置的 loadBalancerIP 来创建负载均衡器。 某些云提供商允许设置 loadBalancerIP。如果没有设置 loadBalancerIP，将会给负载均衡器指派一个临时 IP。 如果设置了 loadBalancerIP，但云提供商并不支持这种特性，那么设置的 loadBalancerIP 值将会被忽略掉。

　　d)ExternalName 类型

　　这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容，例如 www.xcc.com。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

示例：(externelname-svc.yaml)

apiVersion: v1
kind: Service
metadata:
  name: externalname-svc
  namespace: default
spec:
  type: ExternalName
  externalName: www.xcc.com

　　当查询主机 externalname-svc.defalut.svc.cluster.local（svc-name.namespace.svc.cluster.local）时，集群的 DNS 服务将返回一个值 www.xcc.com 的 CNAME 记录。访问这个服务的工作方式和其他的相 同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。

执行命令

[root@master01 ~]# kubectl apply -f externelname-svc.yaml
service/externalname-svc created

[root@master01 ~]# kubectl get svc
NAME               TYPE           CLUSTER-IP    EXTERNAL-IP        PORT(S)      AGE
externalname-svc   ExternalName   <none>        www.xixihaha.com   <none>       4s
kubernetes         ClusterIP      10.96.0.1     <none>             443/TCP      10d

[root@master01 ~]# dig -t A externalname-svc.default.svc.cluster.local. @10.244.0.25
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> -t A externalname-svc.default.svc.cluster.local. @10.244.0.25
......
;; ANSWER SECTION:
externalname-svc.default.svc.cluster.local. 30 IN CNAME    www.xcc.com.
......