kubernetes资源对象kind

PetSet首次在K8S1.4版本中,在1.5更名为StatefulSet。除了改了名字之外,这一API对象并没有太大变化。

注意:以下内容的验证环境为CentOS7、K8S版本1.5.2,并部署SkyDNS。

http://blog.csdn.net/liyingke112/article/details/76685794

https://blog.csdn.net/liyingke112/article/details/76914754

https://kubernetes.io/docs/concepts/storage/volumes/

概念

在云原生应用的体系里,有下面两组近义词;

第一组是无状态(stateless)、牲畜(cattle)、无名(nameless)、可丢弃(disposable);

第二组是有状态(stateful)、宠物(pet)、有名(having name)、不可丢弃(non-disposable)。

无状态:ReplicationController (最初的),ReplicaSet(下一代ReplicationController),Deployment(最新的,更好的管理ReplicaSet和pod) ,具体看(https://blog.csdn.net/Michaelwubo/article/details/80759388)主要是控制无状态服务,Pod的名字是随机设置的,重建后新的Pod名字变了,名字和部署在哪儿都不重要,重要的只是Pod总数。

有状态:PetSet/StatefulSet是用来部署和管理有状态服务。PetSet/StatefulSet中的每个Pod的名字都是事先确定的,不能更改,能提供固定的DNS名称、pod级别的持久化存储和有序podPod名字是用来关联与该Pod对应的状态。

应用场景

有状态服务:数据库服务MySQL和PostgreSQL

集群化管理服务Zookeeper、etcd等有状态服务。

作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物,运维人员需要不断地维护它,容器刚开始流行时,用容器来模拟虚拟机使用,所有状态都保存在容器里,而这已被证明是非常不安全、不可靠的。使用PetSet/StatefulSet,Pod仍然可以通过漂移到不同节点提供高可用,而存储也可以通过外挂的存储来提供高可靠性,PetSet/StatefulSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。

特性

pod稳定的唯一网络标识

拥有固定的:pod名称、主机名、DNS域名等。注意pod的IP地址会变化的。

如果PetSet/StatefulSet名是web,replicas为2,则pod命名:web-0,web-1。并拥有固定的主机名和域名,完整域名格式为pod名.service名.namespace名.svc.域名。

当pod被迁移重新启动后,将保持原有的pod名称重新启动。例如web-0的Pod失败后,K8s将在集群中重启一个同名为web-0的pod。

该域名在集群内可用。这与k8s service的域名有所区别,带主机名的域名能定位到某一个pod主机,而service级别的域名只能定位到某一个服务。

通过一种叫HeadlessService的特殊Service来实现的。和普通Service相比,Headless Service没有Cluster IP,用于为一个集群内部的每个成员提供一个唯一的DNS名字,用于集群内部成员之间通信。

不部署HeadlessService的话,不是使用访问,但可以使用IP地址访问。


pod拥有稳定的持久存储

PetSet/StatefulSet内每一个pod都拥有各自的pvc持久化存储。具体详情https://blog.csdn.net/Michaelwubo/article/details/80759605

该特性能更好的支持分布式集群应用的数据同步,如类似etcd集群这样的有状态应用,节点间是需要进行数据同步的,当etcd集群的某个pod节点重启后,依然能够重新挂载原有的节点数据,重新保持数据复制、同步。

有序启动pod

PetSet/StatefulSet启动pod时,按固定的顺序去启动的,其总是优先启动数字编号更小的Pod。例如:web-0优先于web-1启动,web-1优先于web-2启动。

对于启动顺序有要求的有状态服务来说,该特性是非常重要的。

使用限制

必须部署PV和PVC

    为了让pod拥有稳定的持久存储,必须使用持久化存储PV和PVC,增加了复杂性。详情请见:https://blog.csdn.net/Michaelwubo/article/details/80759605

若PV使用nfs等无法通过调用API来创建存储的网络存储,PVC要在创建PetSet/StatefulSet1前静态创建,如果先创建PetSet/StatefulSet1,而没有创建PVC的话,将会自动创建PVC,但相关参数无法修改;

若为aws-ebs、vSphere、openstack Cinder等可以通过API调用来动态创建存储的虚拟存储,PVC除了可以通过静态的方式创建外,还可以通过StorageClass进行动态创建。

需要注意的是,动态创建出来的PV,默认的回收策略是delete,及在删除数据的同时,还会把虚拟存储卷删除。

删除或缩容PetSet/StatefulSet不会删除对应的存储卷容量。这是为了保证数据的安全,因为对待PetSet/StatefulSet的数据普通的做法比自动回收资源更实用。

必须部署Headless Service

和普通Service相比,Headless Service没有Cluster IP,在PetSet/StatefulSet中起到pod域名解析功能。

如果没有部署HeadlessService的话,PetSet/StatefulSet下的pod,无法通过域名进行访问。

必须手动更新pod

只能通过手动的方式升级PetSet/StatefulSet。

无法使用kubectl edit方式、类似与deployment(kubectl set image)和RC方式升级。能正常使用kubectledit编辑在线yaml文件,即使重启pod所在的node节点,也无法生效。

创建时命名规则有要求

    如下面的例子:

        StatefulSet:StatefulSet名称为lykops-sfs,卷名为pvc

        PV:pv-lykops-sfs-{0,1}

        PVC:pvc-lykops-sfs-{0,1}

    规则如下:

        PVC和PV的命名规则为:资源类型-StatefulSet名称-副本数序号(从0开始)

创建时PV和PVC的yaml规则有要求

    除了命名规则外,还需要保证访问accessModes、resources这两个一样

    按照以上规则创建后,可以看到PV和PVC能关联起来

扩容难

    在扩容前,需要先部署好对应的PV和PVC

节点宕机,pod无法切换

当pod所在节点出现宕机,无法切换到其他node上运行。解决办法是恢复该节点工作。

kubernetes资源对象kind_第1张图片

创建范例

https://blog.csdn.net/Michaelwubo/article/details/80763586

PV

[plain]  view plain  copy
  1. cat << EOF > pv-lykops-sfs-0.yaml  
  2. apiVersion: v1  
  3. kind: PersistentVolume  
  4. metadata:  
  5.  name: pv-lykops-sfs-0  
  6.  labels:  
  7.    type: nfs  
  8.    app: pv  
  9.    version: v1  
  10. spec:  
  11.  capacity:  
  12.    storage: 1Gi  
  13.  accessModes:  
  14.    - ReadWriteMany  
  15.  persistentVolumeReclaimPolicy: Recycle  
  16.   nfs:  
  17.    path: /mysql/data 
  18.    server: 10.30.30.128  
  19.    readOnly: false  
  20. EOF  
  21. kubectl create -f pv-lykops-sfs-0.yaml  

PVC

[plain]  view plain  copy
  1. cat << EOF > pvc-lykops-sfs-0.yaml  
  2. apiVersion: v1  
  3. kind: PersistentVolumeClaim  
  4. metadata:  
  5.  name: pvc-lykops-sfs-0  
  6.  labels:  
  7.    type: nfs  
  8.    app: pvc  
  9.    version: v1  
  10. spec:  
  11.  accessModes:  
  12.    - ReadWriteMany  
  13.  resources:  
  14.    requests:  
  15.      storage: 1Gi  
  16. EOF  
  17. kubectl create -f pvc-lykops-sfs-0.yaml  

Headless Service

[plain]  view plain  copy
  1. cat << EOF >lykops-sfs-headlessservice.yaml  
  2. apiVersion: v1   
  3. kind: Service   
  4. metadata:  
  5.  name: lykops-sfs  
  6.  labels:  
  7.    software: apache  
  8.    project: lykops  
  9.    app: lykops-sfs  
  10.    version: v1  
  11. spec:   
  12.  ports:   
  13.  - port: 80   
  14.    name: apache   
  15.  clusterIP: None   
  16.  selector:   
  17.    software: apache  
  18.    project: lykops  
  19.    app: lykops-sfs  
  20.    version: v1  
  21. EOF  
  22. kubectl create -f lykops-sfs-headlessservice.yaml  

StatefulSet

[plain]  view plain  copy
  1. cat << EOF > lykops-sfs.yaml  
  2. apiVersion: apps/v1beta1   
  3. kind: StatefulSet   
  4. metadata:  
  5.  name: lykops-sfs  
  6.  labels:  
  7.    software: apache  
  8.    project: lykops  
  9.    app: lykops-sfs  
  10.    version: v1  
  11. spec:  
  12.  serviceName: lykops-sfs  
  13.  template:  
  14.    metadata:  
  15.      labels:  
  16.        software: apache  
  17.        project: lykops  
  18.        app: lykops-sfs  
  19.        version: v1  
  20.        name: lykops-sfs  
  21.    spec:  
  22.      containers:  
  23.      - name: lykops-sfs  
  24.        image: hub.c.163.com/library/nginx:latest
  25.        ports:  
  26.        - containerPort: 80  
  27.          name: apache  
  28.        volumeMounts:  
  29.        - name: pvc  
  30.          mountPath: /mnt
  31.  volumeClaimTemplates:  
  32.   -metadata:  
  33.      name: pvc  
  34.    spec:  
  35.      accessModes:  
  36.      - ReadWriteMany  
  37.      resources:  
  38.        requests:  
  39.          storage: 1Gi  
  40. EOF  
  41. kubectl create -f lykops-sfs.yaml  


 




你可能感兴趣的:(kubernetes资源对象kind)