標籤

DaoCloud Enterprise

DCE5 安裝與故障排查整理

1) 安裝超時：context deadline exceeded

現象：Error: context deadline exceeded / client rate limiter Wait returned an error

常見原因：依賴服務未就緒（常見是 Redis + 儲存掛載異常），導致安裝等待超時。

export KUBECONFIG=/root/.kube/config
sudo -E kubectl get pods -n kpanda-system | grep kpanda-bindings-syncer
sudo -E kubectl describe pod kpanda-bindings-syncer -n kpanda-system

sudo -E kubectl get pods -n mcamel-system | grep redis
sudo -E kubectl describe pod rfr-mcamel-common-redis-cluster-1 -n mcamel-system

sudo -E kubectl get pvc -n mcamel-system | grep mcamel-common-redis-cluster
sudo -E kubectl get lvr -n hwameistor
sudo -E kubectl get lsn -n hwameistor

修復：確認 LVR 正常後，刪除卡住 Pod 觸發重建與重新掛載。

sudo -E kubectl delete pod rfr-mcamel-common-redis-cluster-1 -n mcamel-system
sudo ./offline/dce5-installer cluster-create -c ./offline/sample/clusterConfig.yaml -m ./offline/sample/manifest-enterprise.yaml -j12+

2) Ubuntu 火種機空間不足

常見原因：Ubuntu安裝時默認沒有分配所有空間至/上

sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

3) 非 root 部署用戶：三台 Master 上 sudo 免密（可選）

適用時機：僅在使用非 root 用戶（例如 mx）登入並透過 sudo 執行安裝／腳本時需要。若三台 Master 皆以 root 直登且安裝流程不呼叫 sudo -n，可略過本節；可先執行 sudo -n whoami 測試，已成功則不必改。

操作範圍：請在每一台 Master上各自執行（非火種機）；將下方 mx 改為實際部署用戶名。

sudo bash -c 'echo "mx ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/mx'
sudo chmod 440 /etc/sudoers.d/mx
sudo -n whoami

4) DCE5 安裝命令

sudo ./offline/dce5-installer cluster-create -c ./offline/sample/clusterConfig.yaml -m ./offline/sample/manifest-enterprise.yaml -z

5) 接入集群拉取火種鏡像 x509 錯誤

在接入節點設定 containerd registry 跳過 TLS 驗證（範例：172.22.22.215）。

sudo vim /etc/containerd/config.toml
mkdir -pv /etc/containerd/certs.d/172.22.22.215
[plugins.'io.containerd.cri.v1.images'.registry]
  config_path = '/etc/containerd/certs.d'

server = "https://172.22.22.215"
[host."https://172.22.22.215"]
  capabilities = ["pull","resolve"]
  skip_verify = true
cat <<\EOF > /etc/containerd/certs.d/172.22.22.215/hosts.toml
server = "https://172.22.22.215"

[host."https://172.22.22.215"]
  capabilities = ["pull","resolve"]
  skip_verify = true
EOF

systemctl restart containerd kubelet

6) v0.37.0 Issue：部署 Harbor 使用平台 Redis 範本會起不來

現象：在 v0.37.0 透過平台自帶中間件範本快速部署 Harbor 時，Redis 無法正常啟動。

根因：v0.37.0 bootstrap 倉庫使用 Redis 6.2.19，但 PaaS 中間件產生的 Redis 映像仍指向 6.2.12，版本不一致導致部署失敗。

影響：每次透過平台產生 Redis 都需手動進 namespace 修改 RedisFailover CRD 的映像 tag。

臨時處理方式

# 先找到 redisfailover 物件
kubectl get redisfailover -A

# 進目標 namespace 檢查目前 image
kubectl get redisfailover -n <namespace> <name> -o yaml
# 需確認 redis image tag 為 6.2.19（不要是 6.2.12）
spec:
  redis:
    image: "redis:6.2.19"
# 依實際欄位 patch（以下為常見範例）
kubectl patch redisfailover -n <namespace> <name> --type='merge' \
  -p '{"spec":{"redis":{"image":"redis:6.2.19"}}}'

7) 如何使用域名訪問 global cluster

目標：透過自定義域名（例如 dce.custom.com）訪問 global cluster，並使用自定義 TLS 憑證。

步驟 1：升級 ghippo 並配置 reverseProxy

在火種節點使用對應版本安裝包，更新 global.reverseProxy。若有 NodePort，請附加 :<nodeport>。

helm upgrade --reuse-values -n ghippo-system ghippo ./ghippo-0.35.0.tgz \
  --set global.reverseProxy="https://dce.custom.com:<nodeport>"

步驟 2：更新 Istio TLS Secret（用 edit，不要 delete/create）

直接編輯現有 Secret 的 data.tls.crt 與 data.tls.key，避免刪除後被 cert-manager 自動重建。

kubectl edit secret ghippo-gateway-credential -n istio-system
data:
  tls.crt: <base64_of_server.crt>
  tls.key: <base64_of_server.key>

步驟 3：重啟 ghippo-system 相關工作負載

重啟 Deployment 與 StatefulSet，讓服務重新載入配置與憑證。

kubectl rollout restart deployment -n ghippo-system
kubectl rollout restart statefulset -n ghippo-system

如何生成自簽 key/crt（符合 Kubernetes Secret 要求）

注意：Kubernetes TLS Secret 的 data.tls.crt 與 data.tls.key 必須是 base64 編碼字串（單行）。

# 1) 生成私鑰與自簽證書（示例有效期 3650 天）
openssl req -x509 -nodes -newkey rsa:2048 -sha256 -days 3650 \
  -keyout server.key \
  -out server.crt \
  -subj "/CN=dce.custom.com/O=ghippo" \
  -addext "subjectAltName=DNS:dce.custom.com"

# 2) 轉為可貼入 Secret.data 的 base64
CRT_B64=$(base64 < server.crt | tr -d '\n')
KEY_B64=$(base64 < server.key | tr -d '\n')
echo "$CRT_B64"
echo "$KEY_B64"

也可先產生標準 TLS Secret YAML 再取值：

kubectl create secret tls ghippo-gateway-credential \
  --cert=server.crt \
  --key=server.key \
  -n istio-system \
  --dry-run=client -o yaml

8) openEuler 22.03 離線部署缺少 python3-libselinux 套件

現象：使用 openEuler 22.03 作為 OS 底部署時，os-pkgs-openeuler22.03-v0.27.3.tar.gz 內未包含 libselinux 的 Python 依賴，離線環境會缺包。

影響：離線部署流程需要額外手動下載並載入缺失的 RPM。

處理方式：從 openEuler 官方倉庫下載 python3-libselinux-3.3-2.oe2203sp1.x86_64.rpm，再於離線環境中導入安裝。

# 連網環境下載 RPM
wget https://repo.openeuler.org/openEuler-22.03-LTS-SP1/OS/x86_64/Packages/python3-libselinux-3.3-2.oe2203sp1.x86_64.rpm

# 離線環境安裝（擇一）
sudo rpm -ivh python3-libselinux-3.3-2.oe2203sp1.x86_64.rpm
sudo dnf install -y --disablerepo='*' ./python3-libselinux-3.3-2.oe2203sp1.x86_64.rpm

9) 補充案例：MySQL Pod running = 2/4 修復

現象：MySQL Pod 顯示 2/4 Running，常見原因是 /var/lib/mysql 所在磁碟（PVC）已接近或達到 100%。

參考：DaoCloud MySQL Pod 排障中的 Pod running = 2/4 案例。

快速檢查

kubectl get mysql -A
kubectl get pod -n mcamel-system -Lhealthy,role | grep cluster-mysql
kubectl get pod -n mcamel-system | grep cluster-mysql | awk '{print $1}' | \
  xargs -I {} kubectl exec {} -n mcamel-system -c sidecar -- df -h | grep /var/lib/mysql

修復方式（擴容 PVC）

# 找到容量滿載的 PVC（示例）
kubectl get pvc -n mcamel-system | grep mcamel-common-mysql-cluster-mysql

# 編輯對應 PVC，調大 spec.resources.requests.storage
kubectl edit pvc data-mcamel-common-mysql-cluster-mysql-0 -n mcamel-system

修復後驗證

kubectl get pvc -n mcamel-system data-mcamel-common-mysql-cluster-mysql-0
kubectl get pod -n mcamel-system -Lhealthy,role | grep cluster-mysql
kubectl get pod -n mcamel-system | grep cluster-mysql | awk '{print $1}' | \
  xargs -I {} kubectl exec {} -n mcamel-system -c sidecar -- df -h | grep /var/lib/mysql

判斷標準：Pod 回到 4/4 Running 且健康狀態恢復，磁碟使用率低於告警門檻。

10) 補充案例：mcamel-system MySQL 集群 down 連鎖反應

事件摘要：mcamel-common-mysql-cluster-mysql-0 的 PVC 從 15Gi 打滿到 100%，導致 MySQL 不健康，進一步造成自動備份任務連續失敗。

症狀

  • MySQL Pod 長時間卡在 3/4 Running，Readiness 不通過。
  • 備份 Job（mcamel-common-mysql-cluster-auto-*）大量 Error。
  • sidecar 日誌出現備份 API 500 Internal Server Error。

關鍵排查

kubectl get pvc -n mcamel-system data-mcamel-common-mysql-cluster-mysql-0 -o wide
kubectl get statefulset -n mcamel-system mcamel-common-mysql-cluster-mysql -o jsonpath='{.spec.template.spec.containers[?(@.name=="mysql")].readinessProbe}'
kubectl logs -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c init
kubectl logs -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c sidecar
readinessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - test $(mysql --defaults-file=/etc/mysql/client.conf -NB -e 'SELECT COUNT(*) FROM sys_operator.status WHERE name="configured" AND value="1"') -eq 1

真正根因

此案例符合開源 mysql-operator 的已知行為：Pod 自行拉起後，init 可能把 configured 設為 0，但 operator 未自動修復，造成 Pod 長時間停在 3/4 Running（Readiness failed）。

判斷要點：Readiness 檢查依賴 sys_operator.status(name='configured', value='1')；若查到 configured=0，且無明顯主從複製錯誤，通常就是此類問題。

版本註記：與 bitpoke/mysql-operator PR #857 描述的現象一致，但社群後續回報在部分版本仍可重現，建議以「是否命中現象」為主，而非假設版本已完全修復。

官方修復方式（保留資料）

# 檢查 configured 狀態
kubectl exec -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c mysql -- \
  mysql --defaults-file=/etc/mysql/client.conf -e "SELECT * FROM sys_operator.status WHERE name='configured';"

# 方式 1：重啟 mysql-operator（官方建議之一）
kubectl rollout restart statefulset -n mcamel-system mysql-operator

# 方式 2：手工更新 configured（官方建議之一）
kubectl exec -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c mysql -- \
  mysql --defaults-file=/etc/mysql/client.conf -NB -e \
  "update sys_operator.status set value='1' where name='configured';"

# 再次確認
kubectl exec -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c mysql -- \
  mysql --defaults-file=/etc/mysql/client.conf -e "SELECT * FROM sys_operator.status WHERE name='configured';"

修復後驗證

kubectl get pod -n mcamel-system -Lhealthy,role | grep mcamel-common-mysql-cluster-mysql
kubectl describe pod -n mcamel-system mcamel-common-mysql-cluster-mysql-0 | grep -A5 -i readiness
kubectl logs -n mcamel-system mcamel-common-mysql-cluster-mysql-0 -c sidecar --tail=100

若仍為 False，延伸排查（主從同步）

kubectl get mysql -A
kubectl get pod -n mcamel-system -Lhealthy,role | grep cluster-mysql
kubectl get pod -n mcamel-system -Lhealthy,role | grep cluster-mysql | grep replica | awk '{print $1}' | \
  xargs -I {} kubectl logs {} -n mcamel-system -c mysql | grep ERROR

# 進入從庫後執行
kubectl exec -it mcamel-common-mysql-cluster-mysql-1 -n mcamel-system -c mysql -- \
  mysql --defaults-file=/etc/mysql/client.conf -e "show slave status\G"
Labels:

留言

張貼留言