iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 12
0

今天來跟大家介紹 k8s 生態鏈裡面,我個人認為很好用的一個工具,也是 Helm ,那到底 Helm 是什麼? 為什麼需要它,讓我們看下去。

我們先架設一個情境,今天我要部署一個公告服務,那首先我會需要一個 service

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: announcement
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

那當然我們會需要一個 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: announcement-deployment
  labels:
    app: announcement
spec:
  replicas:
  selector:
    matchLabels:
      app: announcement
  template:
    metadata:
      labels:
        app: announcement
    spec:
      containers:
      - name: announcement
        image: announcement
        env:
        - name: MYSQL_ACCOUNT
          value: root
        - name: MYSQL_PASSWORD
          value: TEST1234
        - name: MYSQL_ADDRESS
          value: 127.0.0.1:3306
        ports:
        - containerPort: 80

不知道大家有沒有注意到,上面我們導入了 env。實務上,我們寫好的服務會因應不同站別(DEV、QA、PROD)而有不同的 DB,那如果像我前天天文章有提到的 namespace 實務分享,這樣子的架構下,我們是否要準備三個實體的 Deployment 檔案?如果未來這個 Deployment 需要調整修改,我們就需要須改三次,這聽起來就有軟體設計裡面所講的壞味道吧?

更何況我們所謂的系統怎麼可能只為了公告服務而使用 k8s 呢? 大家可以想像一下像 PCHOME、MOMO 這類大型商城,如果你用微服務來設計它你會設計多少服務呢?我隨便舉一下,如果我來設計至少會有購物車、會員服務、金流管理服務....,那講到這裡各位有發現問題了嗎? 每個服務都需要自己的 Deployment、Services,假設每個服務又要拆成三個站別(DEV、QA、PROD),那你所要管理的yaml檔就是

PCHOME、MOMO 只是筆者拿來舉例,它們實際架構怎樣,背後有沒有運用 k8s,筆者並不清楚。

服務數量 * 2 (Deployment、Service) * 3

這總數會隨著你拆的微服務粒度拆的越細,數量會越恐怖,到最後就會需要有專人來維護這些數量龐大的服務,而且還很容易出錯。

這就是我們要導入 helm 的原因。這邊先簡單介紹為什麼要使用 Helm,後面幾天,我會再詳細介紹它更多的好處,最後還會跟大家介紹我們公司導入 helm 後所受益的事情。

如果不想當一個 yaml 工程師,就讓我們期待一下接下來幾天的介紹。


上一篇
Day11 怎麼部署你第一個 application 到 k3s 裡面
下一篇
Day13 怎麼安裝 helm ?
系列文
k8s 生態鏈 完美組合30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言