Kubernetes全栈架构师（资源调度上）--学习笔记

2021-08-02 20:32:29

目录

  • Replication Controller和ReplicaSet
  • 无状态服务Deployment概念
  • Deployment的创建
  • Deployment的更新
  • Deployment的回滚
  • Deployment扩容和缩容
  • Deployment更新暂停和恢复
  • Deployment更新注意事项
  • 有状态应用管理StatefulSet概念
  • 创建一个StatefulSet应用

Replication Controller和ReplicaSet

Replication Controller（复制控制器，RC）和ReplicaSet（复制集，RS）是两种简单部署Pod的方式。在生产环境中，主要使用更高级的Deployment等方式进行Pod的管理和部署。

  • Replication Controller
  • ReplicaSet

Replication Controller

Replication Controller（简称RC）可确保Pod副本数达到期望值，也就是RC定义的数量。换句话说，Replication Controller可确保一个Pod或一组同类Pod总是可用。

如果存在的Pod大于设定的值，则Replication Controller将终止额外的Pod。如果太小，Replication Controller将启动更多的Pod用于保证达到期望值。与手动创建Pod不同的是，用Replication Controller维护的Pod在失败、删除或终止时会自动替换。因此即使应用程序只需要一个Pod，也应该使用Replication Controller或其他方式管理。Replication Controller类似于进程管理程序，但是Replication Controller不是监视单个节点上的各个进程，而是监视多个节点上的多个Pod。

定义一个Replication Controller的示例如下。

apiVersion: v1

kind: ReplicationController

metadata:

  name: nginx

spec:

  replicas: 3

  selector:

    app: nginx

  template:

    metadata:

      name: nginx

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx

        ports:

        - containerPort: 80

ReplicaSet

ReplicaSet是支持基于集合的标签选择器的下一代Replication Controller，它主要用作Deployment协调创建、删除和更新Pod，和Replication Controller唯一的区别是，ReplicaSet支持标签选择器。在实际应用中，虽然ReplicaSet可以单独使用，但是一般建议使用Deployment来自动管理ReplicaSet，除非自定义的Pod不需要更新或有其他编排等。

定义一个ReplicaSet的示例如下：

apiVersion: apps/v1

kind: ReplicaSet

metadata:

  name: frontend

  labels:

    app: guestbook

    tier: frontend

spec:

  # modify replicas according to your case

  replicas: 3

  selector:

    matchLabels:

      tier: frontend

    matchExpressions:

      - {key: tier, operator: In, values: [frontend]}

  template:

    metadata:

      labels:

        app: guestbook

        tier: frontend

    spec:

      containers:

      - name: php-redis

        image: gcr.io/google_samples/gb-frontend:v3

        resources:

          requests:

            cpu: 100m

            memory: 100Mi

        env:

        - name: GET_HOSTS_FROM

          value: dns

          # If your cluster config does not include a dns service, then to

          # instead access environment variables to find service host

          # info, comment out the 'value: dns' line above, and uncomment the

          # line below.

          # value: env

        ports:

        - containerPort: 80

查看一下使用Deployment来自动管理ReplicaSet

[root@k8s-master01 ~]# kubectl get deploy -n kube-system

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE

metrics-server            1/1     1            1           2d

[root@k8s-master01 ~]# kubectl get deploy -n kube-system metrics-server -oyaml

message: ReplicaSet "metrics-server-64c6c494dc" has successfully progressed.

查看ReplicaSet

[root@k8s-master01 ~]# kubectl get rs -n kube-system

NAME                                DESIRED   CURRENT   READY   AGE

metrics-server-64c6c494dc           1         1         1       2d

如果我们改动了一个参数，做了滚动升级，它就会重新生成一个rs，这个rs可以被回滚，而rc是不支持回滚的，我们一般使用高级的功能比如Deployment和DaemonSet去管理我们的rc或rs，再通过rs管理我们的pod

Replication Controller和ReplicaSet的创建删除和Pod并无太大区别，Replication Controller目前几乎已经不在生产环境中使用，ReplicaSet也很少单独被使用，都是使用更高级的资源Deployment、DaemonSet、StatefulSet进行管理Pod。

无状态服务Deployment概念

用于部署无状态的服务，这个最常用的控制器。一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

Deployment的创建

手动创建

[root@k8s-master01 ~]# kubectl create deployment nginx --image=nginx:1.15.2

deployment.apps/nginx created

导出到nginx-deploy.yaml

[root@k8s-master01 ~]# kubectl get deployment nginx -o yaml > nginx-deploy.yaml

查看nginx-deploy.yaml

[root@k8s-master01 ~]# vim nginx-deploy.yaml

删除status以下的内容，修改副本数

replicas: 2 #副本数

更新配置

[root@k8s-master01 ~]# kubectl replace -f nginx-deploy.yaml

deployment.apps/nginx replaced

查看副本数

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

nginx-66bbc9fdc5-vtk4n   1/1     Running   0          16m

nginx-66bbc9fdc5-x87z5   1/1     Running   0          34s

以上是使用文件的方式管理，也可以使用edit

[root@k8s-master01 ~]# kubectl edit deploy nginx

# 把副本数改回1

replicas: 1

查看副本数

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

nginx-66bbc9fdc5-vtk4n   1/1     Running   0          19m

查看文件

[root@k8s-master01 ~]# cat nginx-deploy.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  annotations:

    deployment.kubernetes.io/revision: "1"

  creationTimestamp: "2021-07-22T08:50:24Z"

  generation: 1

  labels: # Deployment本身的labels

    app: nginx

  name: nginx

  namespace: default

  resourceVersion: "1439468"

  uid: f6659adb-7b49-48a5-8db6-fbafa6baa1d7

spec:

  progressDeadlineSeconds: 600

  replicas: 2 # 副本数

  revisionHistoryLimit: 10 # 历史记录保留的个数

  selector:

    matchLabels:

      app: nginx # 与下面pod的labels必须保持一致，不然管理不了pod，匹配rs，新版本创建之后不允许修改，修改之后产生新的rs，无法对应旧的label

  strategy:

    rollingUpdate:# 滚动升级的策略

      maxSurge: 25%

      maxUnavailable: 25%

    type: RollingUpdate

  template: # pod的参数

    metadata:

      creationTimestamp: null

      labels:

        app: nginx

    spec:

      containers:

      - image: nginx:1.15.2

        imagePullPolicy: IfNotPresent

        name: nginx

        resources: {}

        terminationMessagePath: /dev/termination-log

        terminationMessagePolicy: File

      dnsPolicy: ClusterFirst

      restartPolicy: Always

      schedulerName: default-scheduler

      securityContext: {}

      terminationGracePeriodSeconds: 30

查看deploy的labels

[root@k8s-master01 ~]# kubectl get deploy --show-labels

NAME    READY   UP-TO-DATE   AVAILABLE   AGE   LABELS

nginx   1/1     1            1           22m   app=nginx

状态解析

[root@k8s-master01 ~]# kubectl get deploy -owide

NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES         SELECTOR

nginx   1/1     1            1           40m   nginx        nginx:1.15.2   app=nginx
  • NAME： Deployment名称
  • READY：Pod的状态，已经Ready的个数
  • UP-TO-DATE：已经达到期望状态的被更新的副本数
  • AVAILABLE：已经可以用的副本数
  • AGE：显示应用程序运行的时间
  • CONTAINERS：容器名称
  • IMAGES：容器的镜像
  • SELECTOR：管理的Pod的标签

Deployment的更新

修改spec里面的template才会触发更新

查看镜像版本

[root@k8s-master01 ~]# kubectl get deploy -oyaml | grep image

        - image: nginx:1.15.2

          imagePullPolicy: IfNotPresent

更改deployment的镜像并记录

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:1.15.3 --record

Flag --record has been deprecated, --record will be removed in the future

deployment.apps/nginx image updated

查看滚动更新过程

[root@k8s-master01 ~]# kubectl rollout status deploy nginx

deployment "nginx" successfully rolled out

或者使用describe查看

[root@k8s-master01 ~]# kubectl describe deploy nginx

Events:

  Type    Reason             Age                   From                   Message

  ----    ------             ----                  ----                   -------

  Normal  ScalingReplicaSet  8m37s (x2 over 21h)   deployment-controller  Scaled up replica set nginx-66bbc9fdc5 to 1

  Normal  ScalingReplicaSet  8m35s                 deployment-controller  Scaled down replica set nginx-5dfc8689c6 to 0

  Normal  ScalingReplicaSet  7m41s (x2 over 165m)  deployment-controller  Scaled up replica set nginx-5dfc8689c6 to 1

  Normal  ScalingReplicaSet  7m39s (x2 over 165m)  deployment-controller  Scaled down replica set nginx-66bbc9fdc5 to 0

查看rs

[root@k8s-master01 ~]# kubectl get rs

NAME               DESIRED   CURRENT   READY   AGE

nginx-5dfc8689c6   1         1         1       165m

nginx-66bbc9fdc5   0         0         0       21h

滚动更新的策略是：先启动一个新的rs，将副本数设置为1，再把旧的删掉一个，然后再启动一个新的

查看滚动更新策略配置

[root@k8s-master01 ~]# vim nginx-deploy.yaml

  strategy:

    rollingUpdate:

      maxSurge: 25%

      maxUnavailable: 25%

    type: RollingUpdat

Deployment的回滚

更新deploy镜像

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:787977da --record

Flag --record has been deprecated, --record will be removed in the future

deployment.apps/nginx image updated

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS         RESTARTS   AGE

nginx-5dfc8689c6-ww9v4   1/1     Running        0          17m

nginx-7d79b96f68-m94sh   0/1     ErrImagePull   0          12s

查看历史版本

[root@k8s-master01 ~]# kubectl rollout history deploy nginx

deployment.apps/nginx

REVISION  CHANGE-CAUSE

3         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true

4         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true

5         kubectl set image deploy nginx nginx=nginx:787977da --record=true

回滚到上一个版本

[root@k8s-master01 ~]# kubectl rollout undo deploy nginx

deployment.apps/nginx rolled back

查看pod，可以看到只剩一个

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

nginx-5dfc8689c6-ww9v4   1/1     Running   0          20m

进行多次更新

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:787977da --record

deployment.apps/nginx image updated

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:787977dadaa --record

deployment.apps/nginx image updated

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:787977xxxxxdadaa --record

deployment.apps/nginx image updated

查看历史记录

[root@k8s-master01 ~]# kubectl rollout history deploy nginx

deployment.apps/nginx

REVISION  CHANGE-CAUSE

3         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true

6         kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true

7         kubectl set image deploy nginx nginx=nginx:787977da --record=true

8         kubectl set image deploy nginx nginx=nginx:787977dadaa --record=true

9         kubectl set image deploy nginx nginx=nginx:787977xxxxxdadaa --record=true

查看指定版本的详细信息

[root@k8s-master01 ~]# kubectl rollout history deploy nginx --revision=6

deployment.apps/nginx with revision #6

Pod Template:

  Labels:	app=nginx

	pod-template-hash=5dfc8689c6

  Annotations:	kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.15.3 --record=true

  Containers:

   nginx:

    Image:	nginx:1.15.3

    Port:	<none>

    Host Port:	<none>

    Environment:	<none>

    Mounts:	<none>

  Volumes:	<none>

回滚到执行的版本

[root@k8s-master01 ~]# kubectl rollout undo deploy nginx --to-revision=6

deployment.apps/nginx rolled back

查看deploy状态

[root@k8s-master01 ~]# kubectl get deploy -oyaml

Deployment扩容和缩容

扩容

[root@k8s-master01 ~]# kubectl scale --replicas=3 deploy nginx

deployment.apps/nginx scaled

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

nginx-5dfc8689c6-nhplc   1/1     Running   0          41s

nginx-5dfc8689c6-ww9v4   1/1     Running   0          72m

nginx-5dfc8689c6-xh9l6   1/1     Running   0          41s

缩容

[root@k8s-master01 ~]# kubectl scale --replicas=2 deploy nginx

deployment.apps/nginx scaled

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS        RESTARTS   AGE

nginx-5dfc8689c6-nhplc   1/1     Running       0          2m1s

nginx-5dfc8689c6-ww9v4   1/1     Running       0          73m

nginx-5dfc8689c6-xh9l6   0/1     Terminating   0          2m1s

NAME                     READY   STATUS    RESTARTS   AGE

nginx-5dfc8689c6-nhplc   1/1     Running   0          2m17s

nginx-5dfc8689c6-ww9v4   1/1     Running   0          73m

Deployment更新暂停和恢复

使用edit命令可以修改多个配置，再一次性更新，但是通过set命令，每次都会触发更新，那么该如何做呢？可以使用Deployment更新暂停功能

[root@k8s-master01 ~]# kubectl rollout pause deployment nginx

deployment.apps/nginx paused

使用set命令修改配置

[root@k8s-master01 ~]# kubectl set image deploy nginx nginx=nginx:1.15.3 --record

Flag --record has been deprecated, --record will be removed in the future

# 进行第二次配置变更，添加内存CPU配置

[root@k8s-master01 ~]# kubectl set resources deploy nginx -c nginx --limits=cpu=200m,memory=128Mi --requests=cpu=10m,memory=16Mi

deployment.apps/nginx resource requirements updated

查看deploy

[root@k8s-master01 ~]# kubectl get deploy nginx -oyaml

        resources:

          limits:# 容器最大的CPU和内容容量

            cpu: 200m

            memory: 128Mi

          requests: # 容器启动最小的CPU和内容容量

            cpu: 10m

            memory: 16Mi

查看pod是否被更新

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

nginx-5dfc8689c6-nhplc   1/1     Running   0          22m

nginx-5dfc8689c6-ww9v4   1/1     Running   0          93m

可以看到pod没有更新

更新恢复

[root@k8s-master01 ~]# kubectl rollout resume deploy nginx

deployment.apps/nginx resumed

查看rs

[root@k8s-master01 ~]# kubectl get rs

NAME               DESIRED   CURRENT   READY   AGE

nginx-5475c49ffb   0         0         0       71m

nginx-5dfc8689c6   0         0         0       4h12m

nginx-66bbc9fdc5   0         0         0       23h

nginx-68db656dd8   2         2         2       32s

nginx-799b8478d4   0         0         0       71m

nginx-7d79b96f68   0         0         0       77m

可以看到32s前新增了nginx的rs，更新被恢复就可以创建新的容器了

Deployment更新注意事项

查看deploy

[root@k8s-master01 ~]# kubectl get deploy nginx -oyaml

apiVersion: apps/v1

kind: Deployment

metadata:

  annotations:

    deployment.kubernetes.io/revision: "11"

    kubernetes.io/change-cause: kubectl set image deploy nginx nginx=nginx:1.15.3

      --record=true

  creationTimestamp: "2021-07-22T08:50:24Z"

  generation: 20

  labels:

    app: nginx

  name: nginx

  namespace: default

  resourceVersion: "1588198"

  uid: f6659adb-7b49-48a5-8db6-fbafa6baa1d7

spec:

  progressDeadlineSeconds: 600

  replicas: 2

  revisionHistoryLimit: 10 # 设置保留RS旧的revision的个数，设置为0的话，不保留历史数据

  selector:

    matchLabels:

      app: nginx

  strategy: # 滚动更新的策略

    rollingUpdate:

      maxSurge: 25% # 可以超过期望值的最大Pod数，可选字段，默认为25%，可以设置成数字或百分比，如果该值为0，那么maxUnavailable不能为0

      maxUnavailable: 25% # 指定在回滚或更新时最大不可用的Pod的数量，可选字段，默认25%，可以设置成数字或百分比，如果该值为0，那么maxSurge就不能0

    type: RollingUpdate # 更新deployment的方式，默认是RollingUpdate，滚动更新，可以指定maxSurge和maxUnavailable

  template:

    metadata:

      creationTimestamp: null

      labels:

        app: nginx

    spec:

      containers:

      - image: nginx:1.15.3

        imagePullPolicy: IfNotPresent

        name: nginx

        resources:

          limits:

            cpu: 200m

            memory: 128Mi

          requests:

            cpu: 10m

            memory: 16Mi

        terminationMessagePath: /dev/termination-log

        terminationMessagePolicy: File

      dnsPolicy: ClusterFirst

      restartPolicy: Always

      schedulerName: default-scheduler

      securityContext: {}

      terminationGracePeriodSeconds: 30

status:

  availableReplicas: 2

  conditions:

  - lastTransitionTime: "2021-07-23T07:48:01Z"

    lastUpdateTime: "2021-07-23T07:48:01Z"

    message: Deployment has minimum availability.

    reason: MinimumReplicasAvailable

    status: "True"

    type: Available

  - lastTransitionTime: "2021-07-23T08:10:50Z"

    lastUpdateTime: "2021-07-23T08:10:53Z"

    message: ReplicaSet "nginx-68db656dd8" has successfully progressed.

    reason: NewReplicaSetAvailable

    status: "True"

    type: Progressing

  observedGeneration: 20

  readyReplicas: 2

  replicas: 2

  updatedReplicas: 2

.spec.minReadySeconds：可选参数，指定新创建的Pod在没有任何容器崩溃的情况下视为Ready最小的秒数，默认为0，即一旦被创建就视为可用。

.spec.strategy.type Recreate：重建，先删除旧的Pod，在创建新的Pod

有状态应用管理StatefulSet概念

  • StatefulSet的基本概念
  • StatefulSet注意事项

StatefulSet（有状态集，缩写为sts）常用于部署有状态的且需要有序启动的应用程序，比如在进行SpringCloud项目容器化时，Eureka的部署是比较适合用StatefulSet部署方式的，可以给每个Eureka实例创建一个唯一且固定的标识符，并且每个Eureka实例无需配置多余的Service，其余Spring Boot应用可以直接通过Eureka的Headless Service即可进行注册。

  • Eureka的statefulset的资源名称是eureka，eureka-0 eureka-1 eureka-2
  • Service：headless service，没有ClusterIP eureka-svc
  • Eureka-0.eureka-svc.NAMESPACE_NAME eureka-1.eureka-svc …

StatefulSet的基本概念

StatefulSet主要用于管理有状态应用程序的工作负载API对象。比如在生产环境中，可以部署ElasticSearch集群、MongoDB集群或者需要持久化的RabbitMQ集群、Redis集群、Kafka集群和ZooKeeper集群等。

和Deployment类似，一个StatefulSet也同样管理着基于相同容器规范的Pod。不同的是，StatefulSet为每个Pod维护了一个粘性标识。这些Pod是根据相同的规范创建的，但是不可互换，每个Pod都有一个持久的标识符，在重新调度时也会保留，一般格式为StatefulSetName-Number。比如定义一个名字是Redis-Sentinel的StatefulSet，指定创建三个Pod，那么创建出来的Pod名字就为Redis-Sentinel-0、Redis-Sentinel-1、Redis-Sentinel-2。而StatefulSet创建的Pod一般使用Headless Service（无头服务）进行通信，和普通的Service的区别在于Headless Service没有ClusterIP，它使用的是Endpoint进行互相通信，Headless一般的格式为：

statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local
  • serviceName为Headless Service的名字，创建StatefulSet时，必须指定Headless Service名称；
  • 0..N-1为Pod所在的序号，从0开始到N-1；
  • statefulSetName为StatefulSet的名字；
  • namespace为服务所在的命名空间；
  • .cluster.local为Cluster Domain（集群域）。

假如公司某个项目需要在Kubernetes中部署一个主从模式的Redis，此时使用StatefulSet部署就极为合适，因为StatefulSet启动时，只有当前一个容器完全启动时，后一个容器才会被调度，并且每个容器的标识符是固定的，那么就可以通过标识符来断定当前Pod的角色。

比如用一个名为redis-ms的StatefulSet部署主从架构的Redis，第一个容器启动时，它的标识符为redis-ms-0，并且Pod内主机名也为redis-ms-0，此时就可以根据主机名来判断，当主机名为redis-ms-0的容器作为Redis的主节点，其余从节点，那么Slave连接Master主机配置就可以使用不会更改的Master的Headless Service，此时Redis从节点（Slave）配置文件如下：

port 6379

slaveof redis-ms-0.redis-ms.public-service.svc.cluster.local 6379

tcp-backlog 511

timeout 0

tcp-keepalive 0

……

其中redis-ms-0.redis-ms.public-service.svc.cluster.local是Redis Master的Headless Service，在同一命名空间下只需要写redis-ms-0.redis-ms即可，后面的public-service.svc.cluster.local可以省略。

StatefulSet注意事项

一般StatefulSet用于有以下一个或者多个需求的应用程序：

  • 需要稳定的独一无二的网络标识符。
  • 需要持久化数据。
  • 需要有序的、优雅的部署和扩展。
  • 需要有序的自动滚动更新。

如果应用程序不需要任何稳定的标识符或者有序的部署、删除或者扩展，应该使用无状态的控制器部署应用程序，比如Deployment或者ReplicaSet。

StatefulSet是Kubernetes 1.9版本之前的beta资源，在1.5版本之前的任何Kubernetes版本都没有。

Pod所用的存储必须由PersistentVolume Provisioner（持久化卷配置器）根据请求配置StorageClass，或者由管理员预先配置，当然也可以不配置存储。

为了确保数据安全，删除和缩放StatefulSet不会删除与StatefulSet关联的卷，可以手动选择性地删除PVC和PV

StatefulSet目前使用Headless Service（无头服务）负责Pod的网络身份和通信，需要提前创建此服务。

删除一个StatefulSet时，不保证对Pod的终止，要在StatefulSet中实现Pod的有序和正常终止，可以在删除之前将StatefulSet的副本缩减为0。

创建一个StatefulSet应用

  • 定义一个StatefulSet资源文件
  • 创建一个StatefulSet

定义一个StatefulSet资源文件

[root@k8s-master01 ~]# vim nginx-sts.yaml

# 添加以下内容

apiVersion: v1

kind: Service

metadata:

  name: nginx

  labels:

    app: nginx

spec:

  ports:

  - port: 80

    name: web

  clusterIP: None

  selector:

    app: nginx

---

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: web

spec:

  serviceName: "nginx" # StatefulSet必须配置一个serviceName，它指向已经存在的service，上面定义

  replicas: 2

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      - name: nginx

        image: nginx:1.15.2

        ports:

        - containerPort: 80

          name: web
  • kind: Service定义了一个名字为Nginx的Headless Service，创建的Service格式为nginx-0.nginx.default.svc.cluster.local，其他的类似，因为没有指定Namespace（命名空间），所以默认部署在default。
  • kind: StatefulSet定义了一个名字为web的StatefulSet，replicas表示部署Pod的副本数，本实例为2。

在StatefulSet中必须设置Pod选择器（.spec.selector）用来匹配其标签（.spec.template.metadata.labels）。在1.8版本之前，如果未配置该字段（.spec.selector），将被设置为默认值，在1.8版本之后，如果未指定匹配Pod Selector，则会导致StatefulSet创建错误。

当StatefulSet控制器创建Pod时，它会添加一个标签statefulset.kubernetes.io/pod-name，该标签的值为Pod的名称，用于匹配Service。

创建一个StatefulSet

[root@k8s-master01 ~]# kubectl create -f nginx-sts.yaml

service/nginx created

statefulset.apps/web created

查看pod

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

web-0                    1/1     Running   0          5s

web-1                    1/1     Running   0          3s

查看service

[root@k8s-master01 ~]# kubectl get svc

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE

kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   14d

nginx        ClusterIP   None         <none>        80/TCP    52s

扩容sts

[root@k8s-master01 ~]# kubectl scale --replicas=3 sts web

statefulset.apps/web scaled

查看pod

[root@k8s-master01 ~]# kubectl get po

NAME                     READY   STATUS    RESTARTS   AGE

web-0                    1/1     Running   0          2m21s

web-1                    1/1     Running   0          2m19s

web-2                    1/1     Running   0          14s

新增busybox，解析无头service

cat<<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

  name: busybox

  namespace: default

spec:

  containers:

  - name: busybox

    image: busybox:1.28

    command:

      - sleep

      - "3600"

    imagePullPolicy: IfNotPresent

  restartPolicy: Always

EOF

验证StatefulSet

[root@k8s-master01 ~]# kubectl exec -ti busybox -- sh

/ # ls

bin   dev   etc   home  proc  root  sys   tmp   usr   var

/ # nslookup web-0.nginx

Server:    10.96.0.10

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web-0.nginx

Address 1: 172.25.244.242 web-0.nginx.default.svc.cluster.local

/ # exit

获取pod的IP

[root@k8s-master01 ~]# kubectl get po -owide

NAME                     READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES

busybox                  1/1     Running   0          3m34s   172.25.244.245   k8s-master01   <none>           <none>

nginx-68db656dd8-2dv8l   1/1     Running   0          106m    172.25.244.241   k8s-master01   <none>           <none>

nginx-68db656dd8-8lcrk   1/1     Running   0          106m    172.25.244.240   k8s-master01   <none>           <none>

web-0                    1/1     Running   0          9m3s    172.25.244.242   k8s-master01   <none>           <none>

web-1                    1/1     Running   0          9m1s    172.25.244.243   k8s-master01   <none>           <none>

web-2                    1/1     Running   0          6m56s   172.25.244.244   k8s-master01   <none>           <none>

可以看到它直接把service地址解析成pod的IP，不通过service访问，直接通过IP访问，减少了一层代理，性能更高，所以不需要配置clusterIP

  clusterIP: None

课程链接

http://www.kubeasy.com/

Kubernetes全栈架构师（资源调度上）--学习笔记

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。

上一篇：添物零基础到大型全栈架构师 Java实战及解析（实战篇）- 概述


下一篇：thinkphp框架中处理标签中条件输出