kubernetes进阶之五:Replication Controller&Replica Sets&Deployments

一:Replication Controller

RC是kubernetes的核心概念之一。它定义了一个期望的场景即声明某种Pod的副本数量在任意时候都要符合某个预期值。 它由以下几个部分组成:
1.Pod期待的副本数(replicas)
2.用于筛选目标Pod的Label Selector
3.当Pod的副本数量小于预期数量的时候,用于创建新Pod的Pod模板。

当我们定义了一个RC并提及到kubernetes集群中以后,Master节点上的Controller Manager组件就会得到通知,定期巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于RC的期望值。通过RC,Kubernetes实现了用户应用集群的高可用性,并且大大减少系统管理员在传统IT环境中需要完成的许多手工运维工作。

二:Replica Sets

Replica Sets是下一代的RC,它与RC当前存在的唯一区别是,它支持基于集合的Label selector; 而RC只支持基于等式的Label Selector.
kubectl命令行工具适用于RC的绝大部分命令都同样适用于Replica Sets. 当前我们很少单独使用Replica Set, 它主要被Deployment 这个更高层的资源对象所使用,从而形成一整套Pod创建,删除更新的编排机制。

三:Deployments

Deployments通过Replica Sets实现了对RC的升级。可以随时知道当前Pod部署的进度。典型使用场景有:

  • 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
  • 检查Deployment的状态来看部署动作是否完成(Pod副本的数量是否达到预期的值)。
  • 更新Deployment以创建新的Pod(比如镜像升级)。
  • 如果当前Deployment不稳定,则回滚到一个早先的Deployment版本。
  • 暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项,之后再恢复Deployment,进行新的发布。
  • 扩展Deployment以应对高负载。
  • 查看Deployment的状态,以此作为发布是否成功的指标。
  • 清理不再需要的旧版本ReplicaSets。

下面我们通过运行一些例子来一起直观地感受这个新概念。首先创建一个名为tomcat-deployment.yaml的Deployment描述文件,内容如下:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]} template: metadata: labels: app: app-demo tier: frontend spec: containers: - name: tomcat-demo image: tomcat imagePullPolicy: IfNotPresent ports: - containerPort: 8080  运行下述命令创建Deploymeny: # kubectl create -f tomcat-deployment.yaml deployment "tomcat-deploy" created  运行下述命令查看Deployment的信息: # kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE tomcat-deploy 1 1 1 1 4m 

对上述输出中涉及的数量解释如下:

  • DESIRED:Pod副本数量的期望值,即Deployment里定义的Replica。
  • CURRENT:当前Replica的值,实际上是Deployment所创建的Replica Set里的Replica值,这个值不断增加,直到达到DESIRED为止,表明整个部署过程完成。
  • UP-TO-DATE:最新版本的Pod副本数量,用于指示在滚动升级的过程中,有多少个Pod副本已经成功升级。
  • AVAILABLE:当前集群中可用的Pod副本数量,即集群中当前存活的Pod数量。

运行下述命令查看对应的Replica Set,我们看到它的命名与Deployment的名字有关系:

# kubectl get rs
NAME                        DESIRED     CURRENT     AGE
tomcat-deploy-1640611518    1           1 1m 

运行下述命令查看创建的Pod,我们发现Pod的命名以Deployment对应的Replica Set的名字为前缀,这种命名很清晰地表明了一个Replica Set创建了哪些Pod,对于滚动升级这种复杂的过程来说,很容易排查错误:

# kubectl get pods
NAME                            READY       STATUS      RESTARTS    AGE
tomcat-deploy-1640611518-zhrsc  1/1 Running 0 3m 

运行kubectl describe deployments,可以清楚地看到Deployment控制的Pod的水平扩展过程。





 

转载于:https://www.cnblogs.com/521football/p/10405310.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值