我正在参加「掘金·启航计划」

深入 RC、RS、DaemonSet、StatefulSet

一、RC、RS

RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收

Kubernetes 官方建议使用 RS（ReplicaSet ）替代 RC （ReplicationController ）进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

RC 控制器

apiVersion: v1kind: ReplicationControllermetadata:  name: frontendspec:  replicas: 3  selector:    app: nginx  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: php-redis        image: lansonlinux/myapp:v1        env:        - name: GET_HOSTS_FROM          value: dns          name: zhangsan          value: "123"        ports:        - containerPort: 80

RS 控制器

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: frontendspec:  replicas: 3  selector:    matchLabels:      tier: frontend  template:    metadata:      labels:        tier: frontend    spec:      containers:      - name: myapp        image: lansonlinux/myapp:v1        env:        - name: GET_HOSTS_FROM          value: dns        ports:        - containerPort: 80

二、DaemonSet

DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。

每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
当节点从集群中移除时，Pod 也就被垃圾回收了
删除一个 DaemonSet 可以清理所有由其创建的 Pod

DaemonSet 的典型使用场景有：

在每个节点上运行集群的存储守护进程，例如 glusterd、ceph
在每个节点上运行日志收集守护进程，例如 fluentd、logstash
在每个节点上运行监控守护进程，例如 Prometheus Node Exporter、Sysdig Agent、collectd、Dynatrace OneAgent、APPDynamics Agent、Datadog agent、New Relic agent、Ganglia gmond、Instana Agent 等

apiVersion: apps/v1kind: DaemonSetmetadata: name: logging labels: app: loggingspec: selector: matchLabels: name: logging template: metadata: labels: name: logging spec: containers: - name: logging image: nginx resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi tolerations: #设置容忍master的污点 - key: node-role.kubernetes.io/master effect: NoSchedule

查看效果

kubectl get pod -l name=logging -o wide

三、StatefulSet

有状态副本集；Deployment 等属于无状态的应用部署（stateless）

StatefulSet 使用场景；对于有如下要求的应用程序，StatefulSet 非常适用：

稳定、唯一的网络标识（dnsname）

StatefulSet 通过与其相关的无头服务为每个 pod 提供 DNS 解析条目。假如无头服务的 DNS 条目为: " $(service name).$ (namespace).svc.cluster.local"，那么 pod 的解析条目就是" $(pod name).$ (service name).$(namespace).svc.cluster.local"，每个 pod name 也是唯一的。

稳定的、持久的存储；【每个 Pod 始终对应各自的存储路径（PersistantVolumeClaimTemplate）】

有序的、优雅的部署和缩放。【按顺序地增加副本、减少副本，并在减少副本时执行清理】

有序的、自动的滚动更新。【按顺序自动地执行滚动更新】
限制

给定 Pod 的存储必须由 PersistentVolume 驱动基于所请求的 storage class 来提供，或者由管理员预先提供。

删除或者收缩 StatefulSet 并_不会_删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。

StatefulSet 当前需要无头服务来负责 Pod 的网络标识。你需要负责创建此服务。

当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet 缩放为 0。

在默认 Pod 管理策略(OrderedReady) 时使用滚动更新，可能进入需要人工干预才能修复的损坏状态。

如果一个应用程序不需要稳定的网络标识，或者不需要按顺序部署、删除、增加副本，就应该考虑使用 Deployment 这类无状态（stateless）的控制器

apiVersion: v1kind: Service #定义一个负载均衡网络 metadata: name: stateful-tomcat labels: app: stateful-tomcatspec: ports: - port: 8123 name: web targetPort: 8080 clusterIP: None #NodePort：任意机器+NodePort 都能访问，ClusterIP：集群内能用这个 ip、service 域名能访问，clusterIP: None；不要分配集群 ip。headless；无头服务。稳定的域名 selector: app: stateful-tomcat---apiVersion: apps/v1kind: StatefulSet #控制器。metadata: name: stateful-tomcatspec: selector: matchLabels: app: stateful-tomcat # has to match .spec.template.metadata.labels serviceName: "stateful-tomcat" #这里一定注意，必须提前有个 service 名字叫这个的 replicas: 3 # by default is 1 template: metadata: labels: app: stateful-tomcat # has to match .spec.selector.matchLabels spec: terminationGracePeriodSeconds: 10 containers: - name: tomcat image: tomcat:7 ports: - containerPort: 8080 name: web

#观察效果。删除一个，重启后名字，ip 等都是一样的。保证了状态

#细节 kubectl explain StatefulSet.specpodManagementPolicy： OrderedReady（按序）、Parallel（并发） serviceName -required- 设置服务名，就可以用域名访问 pod 了。 pod-specific-string.serviceName.default.svc.cluster.local

#测试 kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/shping stateful-tomcat-0.stateful-tomcat

#我们在这里没有加存储卷。如果有的话 kubectl get pvc -l app=stateful-tomcat 我们就能看到即使 Pod 删了再拉起，卷还是同样的。

云原生（十六）| Kubernetes 篇之深入 RC、RS、DaemonSet、StatefulSet