今天來跟大家介紹 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 工程師，就讓我們期待一下接下來幾天的介紹。