Kubernetes 網路模型透過扁平化架構和 Service 資源，解決了容器間通訊和服務發現的挑戰。Service 提供了 ClusterIP、NodePort、LoadBalancer 和 ExternalName 四種型別，滿足不同應用場景的需求。Ingress 則作為更進階的外部流量入口，支援多種路由策略，有效簡化服務暴露的複雜度。CNI 外掛是 Kubernetes 網路運作的根本，負責管理容器網路介面和 IP 位址分配，同時也影響叢集的安全性。選擇合適的 CNI 外掛，例如 Calico 或 Cilium，能提升網路效能和安全性。此外，瞭解 Kubernetes 的威脅模型，識別潛在的攻擊面和安全風險，並實施相應的緩解措施，對於保障叢集安全至關重要。
Kubernetes 網路架構深入解析
Kubernetes 網路架構是其叢集運作的核心基礎之一，負責處理容器之間的通訊以及外部請求的路由。在 Kubernetes 中，Service 是抽象化應用程式存取方式的重要資源，而 Ingress 則提供了更進階的外部請求路由管理功能。
Service 型別詳解
Kubernetes 中的 Service 有四種主要型別，分別適用於不同的應用場景和網路需求：
ClusterIP：預設的 Service 型別，僅能在叢集內部存取。適合用於內部服務之間的通訊。
- 技術解析：ClusterIP 依賴 kube-proxy 進行流量轉發，支援 IPTABLES 和 IPVS 兩種模式。其中，IPVS 模式在大規模叢集中表現更優。
- 實務應用：常用於後端服務之間的通訊，例如資料函式庫服務或內部API服務。
NodePort：在每個節點上開放靜態連線埠，允許外部存取 Service。
- 技術挑戰：需要手動管理 IP 位址變化，且每個服務需要獨立的連線埠，難以在大規模環境中使用。
- 改進方案：可結合負載平衡器使用，提升外部存取的彈性。
LoadBalancer：透過雲端服務供應商的負載平衡器暴露服務。
- 成本考量：通常較為昂貴，因為每個 Service 都需要一個獨立的負載平衡器。
- 適用場景：適合需要高用性和彈性擴充套件的生產環境服務。
ExternalName：將 Service 對應到 DNS 名稱，允許透過 CNAME 存取服務。
- 技術優勢：提供彈性的服務發現機制，適合跨叢集或跨雲端的服務整合。
程式碼範例：Service 定義
apiVersion: v1
kind: Service
metadata:
name: example-service
spec:
selector:
app: example-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
內容解密：
apiVersion和kind定義了 Kubernetes 資源的版本和型別。metadata包含了 Service 的名稱和其他元資料。spec.selector指定了 Service 對應的 Pod 標籤選擇器。ports定義了 Service 的連線埠對映規則，將外部的80連線埠轉發到 Pod 的8080連線埠。type指定了 Service 的型別，本例中使用了預設的 ClusterIP。
Ingress：智慧路由解決方案
Ingress 是 Kubernetes 中的一種特殊資源，用於管理外部 HTTP/HTTPS 請求的路由。它提供了比 Service 更靈活的流量管理功能。
Ingress 的主要變體
單一服務 Ingress：將所有流量路由到單一後端服務。
- 技術實作：透過指定預設後端服務，不需要定義任何規則。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: single-service-ingress spec: backend: service: name: service-1 port: number: 80簡單扇出（Simple Fanout）：根據 URL 路徑將流量路由到不同的服務。
- 實務應用：常用於微服務架構，將不同路徑的請求轉發到對應的服務。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: fanout-ingress spec: rules: - host: foo.com http: paths: - path: /foo pathType: Prefix backend: service: name: service-1 port: number: 8080 - path: /bar pathType: Prefix backend: service: name: service-2 port: number: 8080根據名稱的虛擬主機（Name-based Virtual Hosting）：使用不同的主機名稱路由到不同的服務。
- 技術優勢：允許多個網域名稱共用同一個 IP 位址。
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: name-based-virtual-hosting-ingress spec: rules: - host: foo.com http: paths: - path: / pathType: Prefix backend: service: name: service-1 port: number: 80 - host: bar.com http: paths: - path: / pathType: Prefix backend: service: name: service-2 port: number: 80
CNI 與 CNI 外掛簡介
CNI（Container Network Interface）是 Kubernetes 網路架構的核心元件之一，負責管理容器的網路介面。CNI 是 CNCF 的一個專案，提供了一套標準化的容器網路介面規範。
CNI 規範與外掛
CNI 規範主要關注容器的網路連線性和資源清理。當容器被建立或刪除時，CNI 外掛負責設定或清理對應的網路介面。
CNI 與 Kubernetes 網路模型：
- CNI 外掛需要符合 Kubernetes 網路模型的要求，例如 Pod 之間可以直接通訊，無需 NAT。
- kubelet 可以與同一節點上的 Pod 通訊。
常見 CNI 外掛：
- Calico：提供網路策略和安全性功能，適用於大規模叢集。
- Flannel：簡單易用的網路外掛，適合小型叢集。
Calico CNI 外掛深入解析
Calico 是一個流行的 CNI 外掛，提供高效能的網路連線和豐富的網路策略功能。它根據 Linux eBPF 和 iptables 實作高效的封包處理。
apiVersion: projectcalico.org/v3
kind: CalicoNetworkPolicy
metadata:
name: allow-tcp-80
spec:
selector: app == 'example-app'
ingress:
- action: Allow
protocol: TCP
source:
selector: app == 'other-app'
destination:
ports:
- 80
內容解密：
apiVersion和kind定義了 Calico 資源的版本和型別。metadata包含了網路策略的名稱。spec.selector指定了該策略適用的 Pod 標籤選擇器。ingress定義了入口流量的規則，本例中允許來自標籤為app == 'other-app'的 Pod 對連線埠80的 TCP 存取。
Kubernetes 網路架構與 CNI 外掛詳解
Kubernetes 網路架構是其核心功能之一，而 CNI（Container Network Interface）外掛則是實作該架構的關鍵元件。CNI 外掛負責管理容器網路介面、分配 Pod IP 位址以及實施網路策略。
CNI 外掛的任務與功能
CNI 外掛的主要任務包括：
- 管理容器的網路介面
- 為 Pod 分配 IP 位址，通常透過呼叫 IP 位址管理（IPAM）外掛（如
host-local）來完成 - 實施網路策略（選用）
雖然 CNI 規範中並未強制要求網路策略的實作，但 DevOps 在選擇 CNI 外掛時，仍需考慮安全性因素。
主流 CNI 外掛比較
市面上有多種 CNI 外掛可供選擇，如 Calico、Cilium、WeaveNet 和 Flannel 等。根據 Alexis Ducastel 的研究，Calico 和 kube-router 在網路安全方面表現較佳，而 Flannel 則不支援 Kubernetes 網路策略。
CNI 外掛比較
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title CNI 外掛比較
rectangle "支援網路策略" as node1
rectangle "不支援網路策略" as node2
rectangle "支援入口網路策略" as node3
node1 --> node2
node2 --> node3
@enduml
Calico CNI 外掛詳解
Calico 是一款開源的 CNI 外掛，提供雲原生應用連線和策略管理。它與多種協調系統（如 Kubernetes、Apache Mesos、Docker 和 OpenStack）整合良好。Calico 的特點包括：
- 平面 IP 網路：無需 IP 封裝，提供卓越的吞吐量特性。
- 高效能和低資源消耗：根據 Alexis Ducastel 的實驗，Calico 表現出色。
- 全面的網路策略：支援黑名單規則（deny），而 Kubernetes 原生網路策略僅支援白名單規則（allow）。
Calico 元件
在 Kubernetes 中整合 Calico 時，會看到三個元件：
calico/node：DaemonSet 服務，負責程式設計和路由核心路由至本地工作負載，並強制執行本地過濾規則。- CNI 外掛二進位制檔案：包括
calico和calico-ipam，以及與 Kubernetes kubelet 行程整合的設定檔。 - Calico Kubernetes 控制程式：獨立的 Pod，監控 Kubernetes API 以保持 Calico 與 Kubernetes 的同步。
設定 CNI 外掛
要使用 CNI 外掛，需在 Kubernetes 叢集中傳遞 --network-plugin=cni 命令列選項，並透過 --cni-conf-dir 旗標或預設目錄 /etc/cni/net.d 指定設定檔。以下是一個範例設定檔：
{
"name": "k8s-pod-network",
"cniVersion": "0.3.0",
"plugins": [
{
"type": "calico",
"log_level": "info",
"datastore_type": "kubernetes",
"nodename": "127.0.0.1",
"ipam": {
"type": "host-local",
"subnet": "usePodCidr"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "portmap",
"capabilities": {"portMappings": true}
}
]
}
程式碼解析：
此設定檔告訴 kubelet 使用 Calico 作為 CNI 外掛，並使用 host-local 分配 IP 位址給 Pod。其中，portmap 外掛用於支援 hostPort，允許容器埠對映至主機 IP。
使用 kops 建立叢集時指定 CNI 外掛
可以使用 kops 建立叢集時指定 CNI 外掛，例如：
export NODE_SIZE=${NODE_SIZE:-m4.large}
export MASTER_SIZE=${MASTER_SIZE:-m4.large}
export ZONES=${ZONES:-'us-east-1d,us-east-1b,us-east-1c'}
export KOPS_STATE_STORE='s3://my-state-store'
kops create cluster k8s-clusters.example.com \
--node-count 3 \
--zones $ZONES \
--node-size $NODE_SIZE \
--master-size $MASTER_SIZE \
--master-zones $ZONES \
--networking calico \
--topology private \
--bastion='true' \
--yes
程式碼解析：
此範例使用 Calico CNI 外掛建立叢集。透過設定 --networking calico，叢集將使用 Calico 管理網路。
Kubernetes 網路與威脅建模深度解析
在 Kubernetes 生態系統中，網路通訊與安全性是兩個緊密相關且至關重要的議題。本篇文章將探討 Kubernetes 的網路模型、服務暴露方式，以及威脅建模的基本概念和實踐方法。
Kubernetes 網路模型與服務
Kubernetes 的網路模型旨在解決傳統虛擬機器環境中的連線埠資源衝突問題，同時確保應用程式能夠順暢地從虛擬機器遷移到容器化的 Pod 中。該模型的核心特點包括：
- Pod 內部通訊：Pod 內的容器分享相同的網路名稱空間，這意味著它們可以使用 localhost 互相通訊。
- Pod 之間的通訊：Kubernetes 採用扁平化的網路架構，理論上每個 Pod 都可以直接與其他 Pod 通訊，無需使用 NAT。
- 服務發現與負載平衡：Kubernetes 提供了 Service 資源，用於為一組 Pod 提供穩定的網路介面和負載平衡功能。
kube-proxy 的工作原理
kube-proxy 是 Kubernetes 中的關鍵元件，負責實作 Service 的負載平衡功能。它支援多種代理模式，包括使用者空間代理、iptables 代理和 IPVS 代理。其中，IPVS 代理因其高效的負載平衡能力而被廣泛使用。
服務暴露方式
Kubernetes 提供了多種方式將 Service 暴露給叢集外部的使用者端，包括：
- NodePort：在每個節點上開放特定的連線埠，用於將外部流量轉發到對應的 Service。
- LoadBalancer：利用雲端服務提供商的負載平衡器，將外部流量路由到對應的 Service。
- Ingress：提供根據 HTTP/HTTPS 路由的負載平衡和虛擬主機功能，是暴露多個 Service 的高效方式。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
Ingress 的優勢
相較於 LoadBalancer 型別的 Service，Ingress 提供更靈活的路由規則和更高的成本效益，特別是在需要暴露多個 Service 的場景下。
Kubernetes 中的威脅建模
威脅建模是一種在軟體開發生命週期（SDLC）設計階段對系統進行全面分析的方法，用於主動識別和評估系統風險。Kubernetes 生態系統由於其複雜性和多元件特性，引入了多種安全威脅。
威脅建模的關鍵要素
- 資產：需要保護的系統資源或資料。
- 安全控制措施：用於保護資產免受識別出的風險的安全措施或對策。
- 威脅行為者：可能對系統造成威脅的實體或組織。
- 攻擊面：威脅行為者與系統互動的部分，包括進入系統的入口點。
- 威脅：對資產構成的風險。
- 緩解措施：降低威脅發生機率和影響的策略。
Kubernetes 中的威脅
Kubernetes 的預設組態可能無法充分保護佈署的應用程式免受攻擊。瞭解元件之間的互動、識別潛在威脅並制定風險緩解計劃對於確保叢集安全至關重要。
重點回顧
- Kubernetes 網路模型如何解決連線埠資源衝突問題。
- kube-proxy 的工作原理和不同代理模式。
- 各種服務暴露方式（NodePort、LoadBalancer、Ingress）的特點和適用場景。
- 威脅建模在 Kubernetes 安全中的重要性。
- 識別和緩解 Kubernetes 環境中的安全威脅。
在下一章中，我們將進一步探討 Kubernetes 安全的最佳實踐，包括網路策略、身份驗證和授權機制等內容，以幫助讀者構建更安全的容器化應用程式。