修正Calico 3.27升級至新版本後IP Pool無法修改的問題

前情提要，我們在 Calico 3.27 升級至 Calico 3.28 之後的版本都會碰到 Defaul IP Pool 跑回 192.168.x.x 而且改不動的情況。

$ calicoctl version
Client Version:    v3.27.4
Git commit:        2183fee02
Cluster Version:   v3.27.4
Cluster Type:      typha,kdd,k8s,operator,bgp,kubeadm
$ calicoctl get ippool -o wide
NAME       CIDR            NAT    IPIPMODE   VXLANMODE     DISABLED   DISABLEBGPEXPORT   SELECTOR
new-pool   10.244.0.0/16   true   Never      CrossSubnet   false      false              all()

Ubuntu Server延伸Disk與LVM的空間

$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              1.2G  7.7M  1.2G   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   97G   76G   17G  82% /

話說，早期自架 Kubernetes 的 Ubuntu Server，不小心由 PoC 轉正之後，各項 Pod 服務陸續上線。但 PoC 的規格沒開到那麼好，近期發現， LVM（Logical Volume Manager）空間使用率已超過 8 成。在 IT 同事擴充 Disk 容量後，不論 Windows 或 Ubuntu 都一樣，還需要在 OS 層級些設定調整。以下學習一下 Ubuntu Server 如何做延伸 Disk 與 LVM 兩者的磁碟容量。

Kubenetes - apt update GPG EXPKEYSIG error

今天執行 apt update 時出現一個錯誤：

Get:7 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.29/deb  InRelease [1,189 B]
Err:7 https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.29/deb  InRelease
  The following signatures were invalid: EXPKEYSIG 234654DA9A296436 isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://prod-cdn.packages.k8s.io/repositories/isv:/kubernetes:/core:/stable:/v1.29/deb  InRelease: The following signatures were invalid: EXPKEYSIG 234654DA9A296436 isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
W: Failed to fetch https://pkgs.k8s.io/core:/stable:/v1.29/deb/InRelease  The following signatures were invalid: EXPKEYSIG 234654DA9A296436 isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
W: Some index files failed to download. They have been ignored, or old ones used instead.

如何將地端Kubernets叢集加入Azure Arc，以 Kubeadm 建立的Kubernetes叢集為例

Azure Arc系例文章：

1. 如何在Azure Arc加入多台地端VM伺服器
2. 如何為地端伺服器安裝Azure Monitor Agent
3. 如何在Azure Arc加入地端MS SQL Server伺服器
4. 如何將地端Kubernets叢集加入Azure Arc，以Kind為例
5. 如何將地端Kubernets叢集加入Azure Arc，以MicroK8s叢集為例
6. 如何將地端Kubernets叢集加入Azure Arc，以Kubeadm建立的Kubernetes叢集為例
7. 將Azure ExpressRoute with Microsoft Peering環境下的Windows VM加入Azure Arc管理清單
8. 將Azure ExpressRoute with Microsoft Peering下Linux VM加入Azure Arc管理清單
9. 解決ExpressRoute下agentserviceapi.guestconfiguration.azure.com無法連線造成azcmagent連線失敗
10. 取消Azure Arc自動安裝SQL Extension Agent的行為
11. 地端VM升級至Windows Server 2022後，MDE.Windows Extension部署失敗

前面我們利用 Kind 及 MicroK8s 來架設 Kubernetes 叢集，以驗證地端 Kubernetes 叢集與 Azure Arc 的整合，過程也還算順利。接下來，我在同一台 Surface Pro 主機上採用 Hyper-V 並利用Kubeadm 架設的 Kubernetes 叢集來進行再次驗證。當然，有這一篇的出現，代表過程有問題的出現。

$ kubectl get nodes -o wide
NAME     STATUS     ROLES           AGE    VERSION    INTERNAL-IP      EXTERNAL-IP   OS-IMAGE                                    KERNEL-VERSION      CONTAINER-RUNTIME
lnode    Ready      control-plane   111d   v1.26.5    192.168.8.150    <none>        Ubuntu 22.04.2 LTS                          5.15.0-88-generic   containerd://1.6.21
lnode2   Ready      <none>          2d5h   v1.26.11   192.168.8.153    <none>        Ubuntu 22.04.3 LTS                          5.15.0-88-generic   containerd://1.6.24

原生 Kubernetes 的設定步驟均和 MicroK8s 一樣。不過進行到 az connectedk8s connect 步驟時，我得到不一樣的結果：

如何將地端Kubernets叢集加入Azure Arc，以MicroK8s叢集為例

Azure Arc系例文章：

1. 如何在Azure Arc加入多台地端VM伺服器
2. 如何為地端伺服器安裝Azure Monitor Agent
3. 如何在Azure Arc加入地端MS SQL Server伺服器
4. 如何將地端Kubernets叢集加入Azure Arc，以Kind為例
5. 如何將地端Kubernets叢集加入Azure Arc，以MicroK8s叢集為例
6. 如何將地端Kubernets叢集加入Azure Arc，以Kubeadm建立的Kubernetes叢集為例
7. 將Azure ExpressRoute with Microsoft Peering環境下的Windows VM加入Azure Arc管理清單
8. 將Azure ExpressRoute with Microsoft Peering下Linux VM加入Azure Arc管理清單
9. 解決ExpressRoute下agentserviceapi.guestconfiguration.azure.com無法連線造成azcmagent連線失敗
10. 取消Azure Arc自動安裝SQL Extension Agent的行為
11. 地端VM升級至Windows Server 2022後，MDE.Windows Extension部署失敗

首先當然是要準備好 MicroK8s 叢集。

$ kubectl get nodes -o wide
NAME   STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
wk8s   Ready    <none>   14h   v1.28.3   192.168.8.184   <none>        Ubuntu 22.04.3 LTS   5.15.0-89-generic   containerd://1.6.15
mk8s   Ready    <none>   14h   v1.28.3   192.168.8.182   <none>        Ubuntu 22.04.3 LTS   5.15.0-89-generic   containerd://1.6.15

如何將地端Kubernets叢集加入Azure Arc，以Kind為例

Azure Arc系例文章：

1. 如何在Azure Arc加入多台地端VM伺服器
2. 如何為地端伺服器安裝Azure Monitor Agent
3. 如何在Azure Arc加入地端MS SQL Server伺服器
4. 如何將地端Kubernets叢集加入Azure Arc，以Kind為例
5. 如何將地端Kubernets叢集加入Azure Arc，以MicroK8s叢集為例
6. 如何將地端Kubernets叢集加入Azure Arc，以Kubeadm建立的Kubernetes叢集為例
7. 將Azure ExpressRoute with Microsoft Peering環境下的Windows VM加入Azure Arc管理清單
8. 將Azure ExpressRoute with Microsoft Peering下Linux VM加入Azure Arc管理清單
9. 解決ExpressRoute下agentserviceapi.guestconfiguration.azure.com無法連線造成azcmagent連線失敗
10. 取消Azure Arc自動安裝SQL Extension Agent的行為
11. 地端VM升級至Windows Server 2022後，MDE.Windows Extension部署失敗

想要學習如何將地端 Kubernets 叢集加入 Azure Arc，並且利用 Azure Monitor 來監控地端 Kubernets 叢集。架設地端 Kubernets 叢集對我來說已經沒什麼難度了。但對於入門介紹，總不能說，我們要先架個三台地端 Kubernets 叢集，才能開始進入主題吧。借此機會，跟大家介紹一下 Kind 這套架設與測試 Kubernets 叢集的利器。

Azure DevOps進行Kubernetes CD部署時出現憑證錯誤

同事回報，進行 Kubernetes CD 部署時出現錯誤：

couldn't get current server API group list: the server has asked for the client to provide credentials
unable to recognize "...API.yaml": the server has asked for the client to provide credentials

如何快速重新平衡Pod所在的Worker Node - 使用 PowerShell Core

在一個標準 3 台 Node （1 Control Plane + 2 Worker Node）的 Kubernetes 叢集上，在進行維護（drain）之後很容易出現 Pods 集中在某一台 Worker Node 的情況。這在測試區還好，測試區更新極快，通常沒幾天就能回到平衡（Balance）的狀態。正式區就比較麻煩，正式區更新速度不比測試區，因此，Pods 集中在某一台 Worker Node 情況容易時間不短，這會造成特定 Worker Node 資源吃重的情況。針對維護過後，Pods 會集中在某一台 Worker 上，我想改進這一點。

Ubuntu UFW with Kubernetes and Calico Firewall Rules

之前在架設 Kubernetes 叢集預設把防火牆給關閉。當然，關閉防火牆是非常不安全的行為。 當所有 Kubernetes 和 Calico 組態與服務都上線之後，我們需要把防火牆設定回去。

這裡只針對兩個部分：Kubernetes 與 Calico 所以需要埠（Port）。

Calico 3.28.1 IPPool Issue #9100 - Donwngrade solution

我們參考 Calico upgrade docs (uses the operator) 升級了 Calico CNI 元件從 3.27.x 到 3.28.1。

$ calicoctl version
Client Version:    v3.28.1
Git commit:        601856343
Cluster Version:   v3.28.1
Cluster Type:      typha,kdd,k8s,operator,bgp,kubeadm,win

升級後發現，原本的 default-ipv4-ippool 被設定回來了。在 3.27.x，因為一開始沒考慮好網段問題，因此我們設定了一組新的 IPPool 來提供給 Pods 使用，來解決一些 IP 網路的問題。在 3.27 依照 migrate-pools 文件，我們為 default-ipv4-ippool 設定了 disabled: true 並且運作良好。但升級至 3.28.1 後，除了 default-ipv4-ippool 被設定回來並且被啟用了。我們還發現，原始按照文件可以設定 disabled: true 無法被正確套用，刪除指令就算執行成功，其實也是無效的。

$ calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   VXLANMODE     DISABLED   DISABLEBGPEXPORT   SELECTOR
default-ipv4-ippool   192.168.0.0/16   true   Never      CrossSubnet   false      false              all()
new-pool              10.244.0.0/16    true   Never      CrossSubnet   false      false              all()

$ calicoctl get ippool -o yaml > pools.yaml
# add disabled: true
$ vim pools.yaml
$ calicoctl apply -f pools.yaml
Successfully applied 2 'IPPool' resource(s)
# DISABLED : false
$ calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   VXLANMODE     DISABLED   DISABLEBGPEXPORT   SELECTOR
default-ipv4-ippool   192.168.0.0/16   true   Never      CrossSubnet   false      false              all()
new-pool              10.244.0.0/16    true   Never      CrossSubnet   false      false              all()

# delete default-ipv4-ippool
$ calicoctl delete pool default-ipv4-ippool
Successfully deleted 1 'IPPool' resource(s)
$ calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   VXLANMODE     DISABLED   DISABLEBGPEXPORT   SELECTOR
default-ipv4-ippool   192.168.0.0/16   true   Never      CrossSubnet   false      false              all()
new-pool              10.x.0.0/16    true   Never      CrossSubnet   false      false              all()

# use patch method
$ calicoctl patch ippool default-ipv4-ippool -p '{"spec": {"disabled": true}}'
$ calicoctl get ippool -o wide
NAME                  CIDR             NAT    IPIPMODE   VXLANMODE     DISABLED   DISABLEBGPEXPORT   SELECTOR
default-ipv4-ippool   192.168.0.0/16   true   Never      CrossSubnet   false      false              all()
new-pool              10.x.0.0/16    true   Never      CrossSubnet   false      false              all()

[超重要]如何進行自建Kubernetes叢集核心憑證年度更新

最近讀 infoQ 翻譯的一篇Kubernetes 开源 9 年，但我们已经有了 8 年的踩坑血泪史（原文：Lessons From Our 8 Years Of Kubernetes In Production — Two Major Cluster Crashes, Ditching Self-Managed, Cutting Cluster Costs, Tooling, And More），看得心驚膽跳，其中 Kubernetes 憑證沒換把 Kubernetes 叢集搞掛這件事，我已經不只一次在文章裡看到。一般的教學文件會教你如何架 Kubernetes 叢集，教你 Pod、Service、Deployment、Network等等物件的基礎，但很少好好跟你談談憑證這件事。但如果你跟我一樣走自架 Kubernetes 叢集的路，這件事就無比重要，它關係到你的 Kubernetes 叢集的持續運作。這篇我們來解一下 Kubernetes 叢集憑證。

讓地端Kubernetes存取私有Registry-以Azure Container Registry為例

上一篇，是直接透過各種 containerd CLI 來存取 Private Registry 裡的 Images。其實這只算一個 PoC，因為要先學習如何存取私有 Registry。有了之前的經驗，那麼接下來的大目標是讓 Kubernetes 的 nodes 也能存取私有 Registry。之前提到，Kubernetes 本身是使用 crictl CLI 來與 containerd 溝通。

crictl pull --creds "UserName:Password" "ImageDetail"

但我們用 Kubernetes 時不可能這樣下指令，必須透過一些其他方法。Kubernetes 本身可以吃 docker 的 config.json 組態來使用。對「docker 的 config.json 組態」有沒有很熟悉的感覺。對，在上一篇我們透過 nerdctl login 協助，它預設會把相關組態儲存下來到 /root/.docker/config.json，這不就是我們需要的嗎。

教你5分鐘在Ubuntu 22.04架設Kubernetes Cluster

話說[前篇]處理好Notebook、Hyper-V網路與VM網路之間的問題之後，在MicroK8s的幫助下，從Kubernetes到Kubernetes Cluster幾乎都是一行指令就能完成。

安裝MicroK8s：

sudo snap install microk8s --classic --channel=1.25

建立與加入Cluster：

microk8s add-node

方便代表看不到細節。因為想要瞭解細節，因此又花了一些時間學習如何從無到有設定與安裝Kubernetes與建置Kubernetes Cluster。

Windows Server Containers in Google Kubernetes Engine 影片觀後筆記

Windows Server Containers in Google Kubernetes Engine (Cloud Next '19) 筆記

Kubernetes 是一套基於 Google Borg 的容器調度系統(Container Orchestration System)，到目前為止，這些容器一直都是 Linux 容器，運行在 Linux 伺服器上。從開源的 GKE (Google Kubernetes Engine) 1.14 版本開始，支援在 Windows Server 上運行 Windows Container。Google 一直與 Microsoft 與 Kubernetes 社區保持密切合作，並且將結果上傳至開源專案中。GKE 將會在 2019 年提供 Windows 容器，這個場次會討論 Early Access Program(EAP)。這個場次會討論一些 Windows 容器使用者情境並展示產品的初期預覽功能。你也有機會聽到一個大客戶的意見，並且瞭解他們在 GKE 來調度 Windows 和 Linux 容器分析的範例。