OpenShift 容器映像檔建構策略

OpenShift 作為企業級 Kubernetes 平台，提供多種容器映像檔建構方式，滿足不同應用場景需求。S2I 適用於快速建構，但生成的映像檔體積較大，可能包含不必要的建構工具，引入安全風險。Docker 建構提供更高的彈性，但需要自行管理 Dockerfile 和建構環境，安全性也需額外考量。串聯建構結合 S2I 和 Docker 建構的優勢，先利用 S2I 建構應用程式，再以 Docker 建構封裝成精簡安全的映像檔，有效降低安全風險並提升佈署效率。

在 OpenShift 中建構容器映像檔的多種方式

OpenShift 為在 Kubernetes 叢集中建構容器映像檔提供了多種方法，包括 Source-to-Image（S2I）、Docker 建構和串聯建構（Chained Builds）。本篇文章將探討這些方法的優缺點、實作細節和相關技術。

Source-to-Image（S2I）建構

S2I 是一種將原始碼轉換為可執行的容器映像檔的技術。它不需要 Dockerfile，而是使用特定的建構器映像檔來編譯和封裝應用程式。S2I 的優點包括簡化建構流程和提高安全性。然而，它的效能優勢並不比使用叢集本地代理伺服器來管理依賴關係更好。此外，生成的映像檔包含了整個建構環境，這增加了映像檔的大小和潛在的安全風險。

S2I 的缺點

• 生成的映像檔包含建構工具，增加了安全風險
• 映像檔大小增加

Docker 建構

OpenShift 也支援直接在叢集中進行 Docker 建構。Docker 建構透過將 Docker 守護程式的通訊端掛載到建構容器中，然後執行 docker build 命令來工作。Docker 建構的來源可以是 Dockerfile 和上下文目錄，也可以是參照任意映像檔的映像檔來源。

Docker 建構的優點

• 可以使用 Dockerfile 和上下文目錄
• 可以使用映像檔來源

串聯建構（Chained Builds）

串聯建構是一種結合 S2I 和 Docker 建構的技術。它首先使用 S2I 建構生成執行檔，然後使用 Docker 建構建立一個包含執行檔的映像檔。串聯建構可以生成更小的映像檔並提高安全性。

串聯建構的優點

• 生成更小的映像檔
• 提高安全性

範例：使用串聯建構建立應用程式映像檔

下面的範例展示瞭如何使用串聯建構建立一個包含 Java 應用程式的映像檔。首先，使用 S2I 建構生成 JAR 檔案，然後使用 Docker 建構建立一個包含 JAR 檔案的映像檔。

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: runtime
spec:
  source:
    images:
    - from:
        kind: ImageStreamTag
        name: random-generator-build:latest
      paths:
      - sourcePath: /deployments/.
        destinationDir: "."
    dockerfile: |-
      FROM openjdk:17
      COPY *.jar /
      CMD java -jar /*.jar
  strategy:
    type: Docker
  output:
    to:
      kind: ImageStreamTag
      name: random-generator:latest
  triggers:
  - imageChange:
      automatic: true
      from:
        kind: ImageStreamTag
        name: random-generator-build:latest
    type: ImageChange

內容解密：

1. BuildConfig 定義：這是一個 Kubernetes 資源定義，用於描述如何建構應用程式映像檔。
2. 來源設定：指定了用於建構的來源，包括 S2I 建構生成的映像檔和 Dockerfile。
3. Dockerfile：定義瞭如何建構應用程式映像檔，包括基礎映像檔、複製 JAR 檔案和設定啟動命令。
4. 觸發器：當 S2I 建構生成的映像檔更新時，自動觸發 Docker 建構。

更多資訊

• Image Builder 範例
• Image Builders：Buildah、Kaniko、BuildKit 等
• Build Orchestrators：OpenShift Builds、Kbld 等
• Multistage Build、Chaining S2I Builds、Build Triggers Overview 等相關技術檔案。

結語

Kubernetes 已成為佈署和管理容器化分散式應用程式的主要平台。然而，叢集內的應用程式仍然依賴於叢集外的資源，包括資料函式庫、檔案儲存、訊息佇列和其他雲端服務。Kubernetes 的能力並不僅限於管理單一叢集內的應用程式，它還能透過各種雲端服務的操作員來協調叢集外的資源。這使得 Kubernetes API 成為資源期望狀態的唯一「真實來源」，不僅適用於叢集內的容器，也適用於叢集外的資源。

跨越叢集邊界的管理

組織通常需要跨多個資料中心、雲端和 Kubernetes 叢集佈署應用程式，以滿足擴充套件、資料本地化、隔離等需求。同一應用程式或一批應用程式經常需要佈署到多個叢集中，這就需要多叢集佈署和協調。Kubernetes 經常被嵌入到各種第三方服務中，用於跨多個叢集操作應用程式。這些服務利用 Kubernetes API 作為控制平面，每個叢集作為資料平面，讓 Kubernetes 能夠跨多個叢集擴充套件其影響範圍。

Kubernetes 的演進

如今，Kubernetes 已超越了單純的容器協調工具。它能夠管理叢集內、叢集外和多叢集資源，使其成為管理多種資源的通用且可擴充套件的操作模型。其宣告式的 YAML API 和非同步的調解過程已成為資源協調正規化的代名詞。CRD（自定義資源定義）和 Operator 已成為融合領域知識與分散式系統的常見擴充套件機制。

本文涵蓋內容

本文涵蓋了 Kubernetes 中最流行的模式，分為以下幾類別：

基礎模式

代表容器化應用程式必須遵守的原則，以成為良好的雲原生公民。無論應用程式的性質如何，也無論您面臨何種限制，您都應遵循這些準則。遵守這些原則將有助於確保您的應用程式適合在 Kubernetes 上進行自動化。

行為模式

描述 Pod 與管理平台之間的通訊機制和互動。根據工作負載的型別，Pod 可能會作為批次作業執行直到完成，或被排程定期執行。它可以作為無狀態或有狀態服務執行，也可以作為守護程式服務或單例執行。選擇正確的管理原語將幫助您以所需的保證執行 Pod。

結構模式

專注於在 Pod 中構建和組織容器，以滿足不同的使用案例。擁有良好的雲原生容器是第一步，但還不夠。重用容器並將它們組合成 Pod 以實作預期結果是下一步。

組態模式

涵蓋為雲端上的不同組態需求自定義和調整應用程式。每個應用程式都需要組態，沒有一種方法適用於所有情況。我們探討了從最常見到最專門的模式。

安全模式

描述如何在與 Kubernetes 互動的同時約束應用程式。容器化應用程式也有安全層面，我們涵蓋了應用程式與節點、其他 Pod、Kubernetes API 伺服器之間的互動，以及安全的組態。

高階模式

探討了其他類別中不適合的更複雜主題。其中一些模式，如 Controller，已經成熟——Kubernetes 本身就是根據它構建的——而另一些仍在演變中，可能在您閱讀此書時已經發生變化。但這些模式涵蓋了雲原生開發人員應該熟悉的基本概念。

最後的話

如同所有美好的事物一樣，本文也來到了盡頭。我們希望您喜歡閱讀本文，並且它改變了您對 Kubernetes 的看法。我們確信 Kubernetes 及其衍生的概念將會像物件導向程式設計概念一樣基本。本文是我們嘗試為容器協調建立「四人幫設計模式」。我們希望這不是結束，而是您 Kubernetes 之旅的開始；對我們來說，它已經開始了。

祝您 kubectl 操作愉快！

Kubernetes 與雲原生技術深度解析

Kubernetes 作為現代雲原生應用的核心基礎設施，提供了豐富的功能來支援複雜的應用佈署與管理需求。本文將探討 Kubernetes 中的多個關鍵概念與技術，包括服務帳戶（Service Accounts）、資源組態（Resource Profiles）、佈署策略（Deployment Strategies）等，並結合實際案例進行分析。

服務帳戶與安全組態

在 Kubernetes 中，服務帳戶（Service Accounts）是用於識別 Pod 身份的重要機制。它們對於確保應用程式的安全性至關重要。服務帳戶與角色繫結（RoleBindings）結合使用，可以實作細粒度的存取控制。

使用服務帳戶進行身份驗證

服務帳戶主要用於 Pod 與 Kubernetes API 伺服器之間的身份驗證。透過使用服務帳戶，Pod 可以安全地存取 Kubernetes 資源。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceaccount
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-rolebinding
roleRef:
  name: my-role
  kind: Role
subjects:
- kind: ServiceAccount
  name: my-serviceaccount
  namespace: default

內容解密：

1. ServiceAccount 定義：首先定義了一個名為 my-serviceaccount 的服務帳戶。
2. RoleBinding 定義：然後建立了一個 RoleBinding，將 my-role 角色繫結到 my-serviceaccount 服務帳戶上。
3. 作用：這樣，任何使用 my-serviceaccount 的 Pod 都將擁有 my-role 所定義的許可權。

資源組態與 QoS

Kubernetes 允許管理員為 Pod 組態資源需求和限制，這直接影響到 Pod 的 QoS（Quality of Service）等級。QoS 等級分為 Guaranteed、Burstable 和 BestEffort 三類別。

組態資源需求與限制

資源需求（Requests）和限制（Limits）是 Kubernetes 用於排程和管理 Pod 資源使用的關鍵引數。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

內容解密：

1. 資源請求：為容器定義了 CPU 和記憶體的請求值，確保排程器在排程時考慮這些需求。
2. 資源限制：設定了 CPU 和記憶體的使用上限，防止容器超出預期使用過多資源。
3. 作用：透過合理組態資源請求和限制，可以有效管理叢集資源，提高系統的穩定性和效率。

佈署策略

Kubernetes 支援多種佈署策略，包括滾動更新（Rolling Update）、藍綠佈署（Blue-Green Deployment）和金絲雀發布（Canary Release）等。

藍綠佈署實踐

藍綠佈署是一種透過執行兩個相同的生產環境來實作零宕機佈署的策略。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-green-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: my-container
        image: my-app:blue

內容解密：

1. 佈署定義：定義了一個名為 blue-green-deployment 的佈署，初始版本為 blue。
2. 版本標籤：透過 version 標籤區分不同的版本。
3. 作用：在實際佈署時，可以透過切換 Service 的選擇器到不同的版本，實作藍綠佈署。

Kubernetes 技術深度解析與實踐

Kubernetes 作為現代雲原生應用的根本，其強大的容器協調能力與豐富的功能特性，為開發者提供了前所未有的彈性與擴充套件性。本文將探討 Kubernetes 的多個關鍵技術領域，包括佈署策略、服務發現、組態管理、資源排程等，並結合實際案例與最佳實踐，為讀者提供一份全面而深入的技術。

佈署策略與應用管理

Kubernetes 提供了多種佈署策略，以滿足不同應用場景的需求。其中，滾動佈署（Rolling Deployment）是一種常見的策略，能夠在不中斷服務的前提下逐步更新應用版本。此外，宣告式佈署（Declarative Deployment）允許使用者透過定義最終狀態來管理應用佈署，簡化了版本控制與回復流程。

滾動佈署實務

滾動佈署是 Kubernetes 中的一項重要功能，它允許使用者逐步替換舊版本的 Pod，而無需停機維護。透過合理組態 Deployment 資源，可以實作平滑的版本更新。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: example
        image: example:latest
        ports:
        - containerPort: 80

內容解密：

1. strategy.type: RollingUpdate 指定了佈署策略為滾動更新。
2. maxSurge 和 maxUnavailable 用於控制滾動更新的節奏，確保服務的連續性。
3. replicas: 3 定義了應用的副本數量，以實作負載平衡和高用性。

服務發現與內部通訊

在 Kubernetes 中，服務發現（Service Discovery）是實作微服務架構的關鍵技術之一。Kubernetes 提供了多種服務發現機制，包括 DNS Lookup 和環境變數等方式，方便應用間的通訊與協作。

內部服務發現機制

Kubernetes 利用內建的 DNS 服務實作了內部服務發現，允許 Pod 之間透過服務名稱進行通訊，無需依賴外部組態。

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
  - name: http
    port: 80
    targetPort: 8080

內容解密：

1. selector 指定了該服務對應的 Pod 標籤，確保流量被正確路由。
2. ports 定義了服務的埠對映，將外部請求轉發至 Pod 的指定埠。
3. Kubernetes 的內建 DNS 將自動為該服務建立 DNS 紀錄，方便其他 Pod 透過網域名稱存取該服務。

組態管理與安全性

組態管理是 Kubernetes 中的一項重要任務。Kubernetes 提供了 ConfigMap 和 Secret 等資源，用於管理和分發組態資訊與敏感資料。

使用 ConfigMap 管理組態

ConfigMap 允許使用者將組態資料與應用程式碼分離，實作更靈活的組態管理。

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-config
data:
  DATABASE_URL: "postgres://user:password@host:port/dbname"

內容解密：

1. data 部分定義了組態資料，可以在 Pod 中透過環境變數或掛載卷的方式使用。
2. ConfigMap 可以動態更新，但需要應用自行處理組態的熱過載。
3. 將組態與程式碼分離，有助於提升應用的可移植性和可維護性。

資源排程與最佳化

Kubernetes 的排程器負責將 Pod 分配到合適的節點上執行。合理組態資源請求（Resource Requests）和限制（Resource Limits），對於確保應用的效能和穩定性至關重要。

資源組態最佳實踐

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example
    image: example:latest
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "1Gi"

內容解密：

1. requests 定義了容器啟動所需的最低資源量，用於排程決策。
2. limits 設定了容器可使用的最大資源量，防止資源過度消耗。
3. 正確組態資源請求和限制，有助於提升叢集的整體利用率和穩定性。