はじめに
Turbonomic（IBM製のリソース最適化ツール）をAWS EKS上にデプロイする際、内部データベースが使われず、全Podが起動しないという問題に遭遇しました。
原因は、Custom Resource（CR）に設定したexternalDbIPという1行の設定ミスでした。この記事では、同じ問題で悩む方のために、問題の症状・原因・解決手順をまとめます。
対象読者
- Kubernetes/EKSでアプリケーションをデプロイしている方
- Operatorパターンを使ったアプリケーション管理をしている方
- データベース接続でトラブルに遭遇している方
環境
- AWS EKS 1.28
- Turbonomic 8.19.6
- xl-operator（Turbonomic専用Operator）
起きた問題
$ kubectl get pods -n turbonomic
NAME READY STATUS RESTARTS
api-0 0/1 CrashLoopBackOff 10
auth-0 0/1 Init:0/1 0
consul-0 0/1 Running 0
db-0 1/1 Running 0 # ← dbは起動している
repository-0 0/1 Init:0/1 0
# ... 他のPodも起動せず
TurbonomicをEKSに導入する際に、Podが正常に起動しないという問題が起きました。
ポイント：
-
db-0Pod自体は正常に起動している - しかし、他のPodが
dbに接続できず起動失敗 -
apiやauthなどのPodがCrashLoopBackOffやInit:0/1状態
ログで見えた問題
api-0、authなどの特定の起動しないpodのログを見てみました。
$ kubectl logs api-0 -n turbonomic
Error: Cannot connect to database at 10.0.2.15:3306
Connection refused
10.0.2.15 という外部IPへの接続を試みていました。しかし、このIPは存在しない（または到達不可能な）アドレスでした。
Endpointの確認
$ kubectl get endpoints db -n turbonomic
NAME ENDPOINTS AGE
db 10.0.2.15:3306 1h
本来、内部データベース（db-0 Pod）のIPは10.1.x.xのような内部IPのはずですが、10.0.2.15という外部IPが設定されていました。
原因：externalDbIPの誤設定
問題のあったCR設定
apiVersion: ××××××××××××××
kind: Xl
metadata:
name: ××××××××××××××
namespace: turbonomic
spec:
global:
repository: ××××××××××××××
tag: 8.19.6
externalDbIP: "10.0.2.15" # ← これが問題！
storageClassName: gp3-new
# ...
なぜ問題だったのか
今回は内部データベースを使う予定でしたが、誤って外部データベースに接続する設定を書いてしまっていました。
元の誤った設定：
-
externalDbIP: "10.0.2.15"を設定してしまった - この設定により、システムは存在しない「外部データベースを使う」モードになった
- 結果、全Podがデータベースに接続できず起動失敗
正しい設定：
- 内部データベースを使う場合は
externalDbIPを設定しない - 設定しないことで、自動的に内部の
dbPodが使われる
内部データベースを使う場合は何も設定しなくても、Operatorがdb serviceを作成して接続を管理してくれます
解決手順
原因がわかったので、解決した手順に進みます。
ステップ1: 正しいCRファイルを作成
externalDbIPを削除したCRファイルを作成します。
cat > ~/xl-release-fixed.yaml << 'EOF'
apiVersion: ××××××××××××××
kind: Xl
metadata:
name: ××××××××××××××
namespace: turbonomic
spec:
global:
repository: ××××××××××××××
tag: 8.19.6
storageClassName: gp3-new
storageSelector: false
enableExternalSecrets: false
hostingPlatform: eks
hostingProvider: aws
ingress:
annotations:
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
service.beta.kubernetes.io/aws-load-balancer-type: nlb
aws:
enabled: true
nginx:
nginxIsPrimaryIngress: true
# 不要なターゲットは無効化
actionscript:
enabled: false
# ... (他のターゲットも同様)
EOF
externalDbIPの行がないことを確認してください。
ステップ2: 既存のCRを削除
kubectl delete xl xl-release -n turbonomic
もし削除が進まない場合（Finalizerが残っている場合）：
kubectl patch xl xl-release -n turbonomic \
-p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl delete xl xl-release -n turbonomic --force --grace-period=0
ステップ3: 正しいCRを適用
kubectl apply -f ~/xl-release-fixed.yaml
ステップ4: 全Podを再起動
設定変更を確実に反映させるため、全Podを再起動します。
kubectl delete pods --all -n turbonomic
Operatorが自動的にPodを再作成します。
ステップ5: 確認（5分後）
# Endpoint確認
kubectl get endpoints db -n turbonomic
期待される結果：
NAME ENDPOINTS AGE
db 10.1.45.123:3306 2m
↑ 内部IP（10.1.x.x）になっている
# Pod状態確認
kubectl get pods -n turbonomic
期待される結果：
NAME READY STATUS RESTARTS
api-0 1/1 Running 0
auth-0 1/1 Running 0
consul-0 1/1 Running 0
db-0 1/1 Running 0
repository-0 1/1 Running 0
# ... 全てのPodがRunning
まとめ
学んだことをまとめます。今回の問題は、CRの設定が原因でした。
-
正しい設定の理解
CRは設定内容がそのまま反映されるため、各パラメータの意味を正しく理解し、意図した設定になっているかを丁寧に確認する。
# 必須設定
storageClassName: gp3-new # ストレージクラスは明示的に指定
# 不要な設定（デフォルトで動作）
# externalDbIP: "..." # 内部DBを使う場合は設定しない
-
Endpointリソースで接続先を確認
Kubernetesでは、Serviceの実際の接続先はEndpointリソースで確認できます。DB接続の問題では、エンドポイントを確認することでどこに接続しようとしているか確認する。
kubectl get endpoints <service-name> -n <namespace>