• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

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

开发技术 开发技术 3周前 (09-12) 22次浏览

一、定义和分类

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.
......

 


喜欢 (0)