深入剖析Kubernetes--第五章:Kubernetes编排原理_控制器_StatefulSet(2)

StatefulSet(二)

Kubernetes 项目引入了一组叫作 Persistent Volume Claim(PVC)和 Persistent Volume(PV)的 API 对象

定义一个 PVC,声明想要的 Volume 的属性

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

在应用的 Pod 中,声明使用这个 PVC:

apiVersion: v1
kind: Pod
metadata:
  name: pv-pod
spec:
  containers:
    - name: pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-storage
  volumes:
    - name: pv-storage
      persistentVolumeClaim:
        claimName: pv-claim

Pod 的 Volumes 定义中,只需要声明它的类型是 persistentVolumeClaim,然后指定 PVC 的名字,而完全不必关心 Volume 本身的定义。

在StatefulSet中声明PVC

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

StatefulSet 额外添加了一个 volumeClaimTemplates 字段。凡是被这个 StatefulSet 管理的 Pod,都会声明一个对应的 PVC;而这个 PVC 的定义,就来自于 volumeClaimTemplates 这个模板字段。同时,这个 PVC 的名字,会被分配一个与这个 Pod 完全一致的编号。

这个自动创建的 PVC,与 PV 绑定成功后,就会进入 Bound 状态,这就意味着这个 Pod 可以挂载并使用这个 PV 了。

PVC 与 PV 的绑定得以实现的前提是,运维人员已经在系统里创建好了符合条件的 PV;或者,你的 Kubernetes 集群运行在公有云上,这样 Kubernetes 就会通过 Dynamic Provisioning 的方式,自动为你创建与 PVC 匹配的 PV。

kubectl get pvc
NAME          STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-web01-0   Pending                                                     12s

PVC,都以“<PVC 名字 >-<StatefulSet 名字 >-< 编号 >”的方式命名,并且处于 Bound 状态。(pend是因为没建立PV)

总结

StatefulSet 的控制器直接管理的是 Pod。这是因为,StatefulSet 里的不同 Pod 实例,不再像 ReplicaSet 中那样都是完全一样的,而是有了细微区别的。比如,每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式,就是通过在 Pod 的名字里加上事先约定好的编号

Kubernetes 通过 Headless Service,为这些有编号的 Pod,在 DNS 服务器中生成带有同样编号的 DNS 记录。只要 StatefulSet 能够保证这些 Pod 名字里的编号不变,那么 Service 里类似于 web-0.nginx.default.svc.cluster.local 这样的 DNS 记录也就不会变,而这条记录解析出来的 Pod 的 IP 地址,则会随着后端 Pod 的删除和再创建而自动更新。这当然是 Service 机制本身的能力,不需要 StatefulSet 操心。

StatefulSet 还为每一个 Pod 分配并创建一个同样编号的 PVC。这样,Kubernetes 就可以通过 Persistent Volume 机制为这个 PVC 绑定上对应的 PV,从而保证了每一个 Pod 都拥有一个独立的 Volume。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kubernetes(简称K8s)是一个开源的容器编排平台,主要用于自动化部署、扩展和管理容器化应用程序。它提供了一种通用的方法来管理分布式系统,并提供了跨多个主机的容器的自动化部署、弹性伸缩、负载均衡和自动故障恢复等功能。 在深入剖析Kubernetes之前,我们先了解一些关键概念: 1. Pod:是Kubernetes调度的最小单位,可以包含一个或多个容器。这些容器在同一个Pod中共享网络和存储资源。 2. Node:是Kubernetes集群的工作节点,可以是物理机或虚拟机。Node上运行着Kubernetes的各个组件,并用于运行Pod。 3. Deployment:用于定义应用程序的部署方式,包括Pod的副本数量、更新策略等。 4. Service:提供了一种访问Pod的方式,可以通过Service的IP和端口访问Pod。 5. Namespace:用于在集群中创建虚拟的资源分组,使不同的团队或项目能够隔离使用集群资源。 6. Label和Selector:Label是键值对,用于标识资源,而Selector则用于根据Label选择相应的资源。 Kubernetes内部有多个核心组件,包括: 1. kube-apiserver:提供Kubernetes API,用于管理集群的各种操作和资源。 2. kube-controller-manager:包含多个控制器,用于监控集群状态并进行自动化管理,例如副本数量调整、滚动更新等。 3. kube-scheduler:负责为新创建的Pod选择合适的Node进行调度,并考虑资源约束和亲和性策略等。 4. kubelet:运行在每个Node上,负责管理Pod的生命周期,包括容器的创建、启动和停止等。 5. kube-proxy:负责为Service提供网络代理和负载均衡功能。 Kubernetes通过使用这些组件实现了容器的自动化部署和管理。它具有高可用性、弹性伸缩、自动故障恢复等特性,可以轻松管理大规模的容器化应用程序。同时,Kubernetes还提供了丰富的扩展机制和插件生态系统,可以满足不同场景下的需求。 总结来说,Kubernetes是一个强大的容器编排平台,通过抽象和自动化的方式简化了容器化应用程序的部署和管理。它在云原生应用开发和运维中扮演着重要角色,帮助用户实现高效、可靠和可扩展的容器化部署。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值