Day13-Kubernetes 那些事 - Deployment 与 ReplicaSet(一)

前言

昨天的文章介绍完 Replication Controller 相信大家应该对於 K8s 是如何控制 Pod 有了初步的了解了,其实真正实务上是比较少用 Replication Controller 进行 Pod 控制,都是用 Deployment 搭配 ReplicaSet 进行控制,接下来的文章就来讲讲这两个物件吧!

由於 Deployment 能讲的东西真的太多了,所以笔者会拆成三篇文章来介绍,方便读者消化全部的内容,废话不多说开始系列文的第一篇内容吧!

什麽是 ReplicaSet?

看到 Replica 的读者应该就知道这个跟控制 Pod 的数量又有关系了,其实 ReplicaSet 跟 Replication Controller 很像,差别在於 ReplicaSet 提供了更弹性的 selector,在 Replication Controller 中我们必须要把完整的 key/value pair Label 写上去,在 ReplicaSet 中则不用这麽麻烦,但 ReplicaSet 一样也可以写上完整的 Label 就看开发者要如何设计。

ReplicaSet 特性

上面提到 ReplicaSet 有非常弹性的 selector 这边就来讲一下 ReplicaSet 是如何让 selector 变得更加弹性,这里一共要介绍两种 ReplicaSet 的 selector 写法。

  • matchLabels

    matchLabels 其实跟一般的 selector 做的事情一模一样,也是要写出完整的 Label 出来,整体来说写法会长的像这样:

    selector:
      matchLabels:
        app: frontend
    
  • matchExpressions

matchExpressions 则是提供更弹性的选取条件,每一笔条件主要由 key、 operator、value 组成,并用一个 {} 包起来,整个看起来会很像 JS 的物件型态,整体来说写法会长的像这样:

selector:
 matchExpression:
   - {key: app, operator: In, values: [frontend, backend]}

看起来好像很复杂但其实很简单,上面范例中的 Expression 翻成中文就是只要 Label 的 key 是 app 而且其值有符合 [frontend, backend] 阵列中的其中一个值的 Pod 就会被选取到。

所以同理可证假如今天有一个 matchExpression 长得像这样:

selector:
 matchExpression:
   - {key: env, operator: NotIn, values: [dev, canary]}

这句话就可以依样画葫芦知道要选取的是 Label 中 key 为 env 且其值并不是 [dev, canary] 中其中一个值的 Pod 。

什麽是 Deployment?

在开始介绍 Deployment 之前,这边笔者要复制一段官网上的文字:

a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features.

官网这段文字写得非常好,告诉我们 Deployement 其实就是一种负责管理 ReplicaSet 以及控制 Pod 更新的物件,在先前的文章都没有提到 Pod 的更新是因为 Pod 无法直接更新,必须要砍掉重建才会是新的内容,有了 Deployment 之後我们就可以很方便的进行 Pod 的更新了。

由於 ReplicaSet 本身也会控制 Pod ,所以整个整体看起来就会像是 Deployment 控制着 Pod ,但其实Deployment 真正控制的是 ReplicaSet 喔!

所以整体来说 Deployment 再加上 ReplicaSet 的架构会长得像这样:

Deployment 特性

  • 部署一个应用服务

    上面提到 Deployment 可以帮助 Pod 进行更新,通常在开发一个产品的时候一定会不断的更新,透过 Deployment 我们就可以快速的帮 Pod 更新内部的 container,所以通常在部署应用的时候都会使用 Deployment。

  • 在服务升级的过程中可以达到无停机服务迁移(zero downtime deployment)

    在 Deployment 进行内部 Pod 更新的过程中会有一个专有名词叫 RollingUpdate,RollingUpdate 翻成中文就是滚动更新的意思,在更新的过程中 Deployment 会先产生一个新的 ReplicaSet 而这个 ReplicaSet 内部的 Pod 会运行新的内容,待新的 Pod 被 K8s 确认可以正常运作时 Deployment 就会将旧的 ReplicaSet 进行取代的动作,这样就达到无停机服务迁移了。

  • 可以 Rollback 到先前版本

    每一次 Deployment 在进行滚动更新的时候都会把当前的 ReplicaSet 做一个版本控制的纪录,跟 git commit 很像,利用这些纪录就可以快速的恢复成之前的版本,这些 Pod 也就会变成先前的内容。

小结

今天介绍了 Deployment 最基本的观念,相信读者应该对 Deployment 有了初步的了解了。

接下来的文章要介绍 Deployment 如何撰写以及建立,如果对於文章有任何问题都欢迎留言给我,那我们就下一篇文章见喽~


<<:  JavaScript学习日记 : Day16 - Promise

>>:  【Day12】插槽 Portals

【Day30-回首】成为最晚报名的完赛选手!——心得与文章整理

耶终於来到最後一天了,就稍微整理一下文章和心得 文章整理 基本观念与心得类 【Day01-资料】什麽...

SQL MD5 加密 & C# BASE64

C# BASE64 原由:厂商丢了编成 Base64 字串的东西来,接到後,要把它还原. strin...

DAY5-PHP这是什麽老东西

前言: PHP(Hypertext Preprocessor)作为网页开发的先驱,可是不知道是因为...

[Day21]Palindromes

上一篇介绍了The Huge One,这题因为数字太大,所以选择使用了BigInteger,当然各位...

JavaScript学习日记 : Day12 - Event Loop

1.为何Event Loop存在? 主要的原因有两个 : 图片来源:Event loop and t...