• k8s控制器详解(重要)


    目录

    • 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
  • 相关阅读:
    java内联函数
    jvm垃圾回收
    jvm内存管理
    java进程和线程的区别
    jvm
    简单易学的SSM(Spring+SpringMVC+MyBatis)整合
    Spring之声明式事务
    SpringMVC知识点小结
    Servlet之文件的上传与下载
    java使用字节流和字符流实现文件复制
  • 原文地址:https://www.cnblogs.com/cheyunhua/p/15801549.html
Copyright © 2020-2023  润新知