Slide 1
Slide 1 text
1
進化するK8s運⽤
KarpenterによるCluster
Autoscalerからの脱却
運⽤ノウハウ完全公開
柴⽥ 巧平
Slide 2
Slide 2 text
2
⾃⼰紹介
技術部 技術基盤グループ
柴⽥ 巧平 Kohei Shibata
複数サービスのKuberntesクラスタの設計、構築、
運⽤からセキュリティ対策までプラットフォーム基
盤の整備を幅広く担当している。特にAWSでのプ
ラットフォーム基盤の設計、構築に強み。そのほ
か、⾃社運⽤のプライベートクラウド基盤での構築
や運⽤も。
● Twitter : @hokatabi
Slide 3
Slide 3 text
3
GMOペパボはマルチブランド戦略で展開しております
etc…
Slide 4
Slide 4 text
4
GMOペパボはマルチブランド戦略で展開しております
この2つのサービスの
Kubernetesクラスタの話
Slide 5
Slide 5 text
5
アジェンダ
1. Karpenter⼊⾨編
1.1. 特徴
1.2. Cluster Autoscalerとの違い
2. インストール編
2.1. インストールはなにをするのか
2.2. 絶対にやるべき設定
3. 運⽤編
3.1. nodeclass, nodepool
3.2. 避けた⽅がよい設定
3.3. できていないがやりたかったこと
Slide 6
Slide 6 text
1. Karpenter⼊⾨編
6
Slide 7
Slide 7 text
Karpenter⼊⾨編
7
https://tech.pepabo.com/2023/12/22/cloudnative-days-tokyo-2023/
Karpenterを知ったのはCloudNative Days Tokyo 2023
Slide 8
Slide 8 text
Karpenter⼊⾨編
8
● この頃SUZURIをとあるPaaS→EKSに移⾏する検証をしていた
● なるべく運⽤開始後にKubernetesの運⽤負荷が低くできないか…
● その頃の⾃分のあたまでは以下の選択肢があった
○ EKS (on EC2)
■ ちゃんとノードグループの設計をしてメンテナンスをしないといけないイメージ
■ インスタンスタイプを利⽤するアプリケーションリソースに合わせて…⼿間
○ EKS (on Fargate)
■ ノード部分が抽象化されているので運⽤はラクできそう
■ Spotインスタンスが使えない / Daemonsetが使えない
● ここで知った第3の選択肢、EKS(on EC2) + Karpenter
Karpenterを知ったのはCloudNative Days Tokyo 2023
Slide 9
Slide 9 text
Karpenter⼊⾨編
9
● ʻKubernetesクラスター⽤のノードの動的なスケールアウトとスケールインを⾃動
化するノードプロビジョナー’
● AWS EKSで動く(他、Azure AKS)
● この登壇ではAWS EKSでの動作について扱います
● EKS (on EC2)と組み合わせて動く
● 最近(2024/12)リリースされた EKS Auto Modeは Karpenterでの運⽤が前提
● EC2の運⽤負荷が低減でき、Spotインスタンスが使えてDaemonsetも普通に使える
いいとこ取り
Karpenterをひとことで⾔うと
Slide 10
Slide 10 text
Karpenter⼊⾨編
10
コスト最適化がラクにできる！！！
● ⾃動で最適なノード台数をprovisionsしてくれる
○ Podのresource requestベース
● インスタンスタイプの中から最適なものを⾃動で選択する
● 強⼒なSpotインスタンスを⽤いたコスト最適化設計
○ 「スポットインスタンスのベストプラクティス」に沿いやすい
■ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-best-practices.html
● ノードの起動が早い
○ EC2のAPIを直接実⾏するため
Karpenterの特徴
Slide 11
Slide 11 text
Karpenter⼊⾨編
11
1. デプロイ
● CA: ノードグループに依存したスケーリング設定。
● Kar: ノードグループに依存しない。よりシンプルなスケーリング設定。
2. インスタンスタイプ、spot, on-demand設定
● CA: ノードグループとインスタンスタイプが1:1。また、spot / on-demandのどち
らかを選択。 複数インスタンスタイプを使う場合はその分ノードグループが必要。
● Kar: 1つのノードプールで複数のインスタンスタイプから⾃動選択、reserved /
spot / on-demand から⾃動選択。設定が少なくて済む。
Cluster Autoscalerとの⽐較(1)
Slide 12
Slide 12 text
Karpenter⼊⾨編
12
3. スケーリング速度
● CA: Karより遅い。CA→ノードグループ→オートスケーリンググループ→EC2
● Kar: CAより速い。 Karpenter→EC2
4. Spotインスタンスの終了への対応
● CA: キャパシティリバランシングで事前に別のSpotインスタンスを起動。または中
断通知によるdrain。
● Kar: 中断通知によるdrainのみ。
Cluster Autoscalerとの⽐較(2)
Slide 13
Slide 13 text
Karpenter⼊⾨編
13
Cluster Autoscalerとの⽐較(まとめ)
Karpenterのアドバンテージ
● シンプルな設定で複数のインスタンスタイプやspotインスタンスへの対応ができる
● 少ないノードグループ
● スケーリングが速い
● Reserved Instanceへの対応
Cluster Autoscalerのアドバンテージ
● Spotインスタンスのオートリバランシング
Slide 14
Slide 14 text
14
Karpenter⼊⾨編
特にSpotインスタンスを積極活⽤したい⼈には絶対おすすめ
“ ほったらかしでコスト最適化したい”
結局、こういう⼈におすすめ
Slide 15
Slide 15 text
Karpenter⼊⾨編
15
● KarpenterはEKSやAKSで動作するノードプロビジョナー
● EKS Auto Modeで採⽤され、EKSでは今後の標準になっていきそう
● Cluster Autoscalerと⽐較して、少ない設定でコスト最適化ができる
● Spotインスタンスでのコスト最適化がやりやすい
● Reserved InstanceとSpotインスタンスを組み合わせたコスト最適化もできる
● ⾃動化の範囲が広く、少ない設定でコスト最適化ができる
⼊⾨編まとめ
Slide 16
Slide 16 text
2. インストール編
16
Slide 17
Slide 17 text
インストール編
17
● ⼀度もスッとインストールできた経験がないから…
● ⾃分は4度インストールとアップデートの経験をした
○ SUZURI クラスタサービスイン(v0.36)
○ minne クラスタ Cluster Autoscalerからの切り替え(v1.0.2) 👈特に苦労した
○ SUZURI Karpenterアップデート (v0.36 → v1.3.3) 👈特に苦労した
○ minne Karpenterアップデート (v1.0.2 → v1.3.3)
● なぜ苦労したのか、どうすれば苦労せずに済むかをお伝えしたい
なぜインストール編があるか
Slide 18
Slide 18 text
インストール編
18
● CloudFormation テンプレートをダウンロード & デプロイする
● eksctlコマンドでクラスタを作成する
● helmでKarpenterをインストールする
● Karpenterの設定(NodeClass, NodePool)を定義する
https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/
ね？簡単でしょ？ … とはいかない
公式のインストール⼿順
Slide 19
Slide 19 text
インストール編
19
● CloudFormation & eksctlコマンドを使う前提であり、 Terraformを
使うことは想定されていない 🤔
● クラスタを新規作成する前提でインストール手順がある 🤔
● AWSサービスはすべてTerraformで管理している
● CloudFormationと棲み分け考えて周知するのは面倒
Slide 20
Slide 20 text
インストール編
20
CloudFormationで何をやっているかを紐解いて、Terraformコードにする
curl -fsSL
https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION
}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloud
formation.yaml > "${TEMPOUT}" \
&& aws cloudformation deploy \
--stack-name "Karpenter-${CLUSTER_NAME}" \
--template-file "${TEMPOUT}" \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides "ClusterName=${CLUSTER_NAME}"
↓ドキュメントではcurlでCloudFormationのtemplateを取得してdeployしている
Slide 21
Slide 21 text
インストール編
21
CloudFormationで何をやっているかを紐解いて、Terraformコードにする
curl -fsSL
https://raw.githubusercontent.com/aws/karpenter-provider-aws/v"${KARPENTER_VERSION
}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloud
formation.yaml > "${TEMPOUT}" \
&& aws cloudformation deploy \
--stack-name "Karpenter-${CLUSTER_NAME}" \
--template-file "${TEMPOUT}" \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides "ClusterName=${CLUSTER_NAME}"
↓ドキュメントではcurlでCloudFormationのtemplateを取得してdeployしている
● こちとら全部Terraformでコード管理しているんですけど …
Slide 22
Slide 22 text
インストール編
22
CloudFormationで何をやっているかを紐解いて、Terraformコードにする
https://raw.githubusercontent.com/aws/karpenter-provider-aws/v1.3.2/website/content/en/preview/getting-
started/getting-started-with-karpenter/cloudformation.yaml
AWSTemplateFormatVersion: "2010-09-09"
Description: Resources used by https://github.com/aws/karpenter
Parameters:
ClusterName:
Type: String
:
:
Targets:
- Id: KarpenterInterruptionQueueTarget
Arn: !GetAtt KarpenterInterruptionQueue.Arn
350行くらい
Slide 23
Slide 23 text
インストール編
23
● Karpenter Controller⽤のIAM Role/ IAM Policy の作成
○ Karpenterの機能が動作するための権限
■ EC2を起動する権限など
■ これがないとNodeClassがうまく起動しない
● Karpenter Node⽤のIAM Role / IAM Policyの作成
○ CNIやSSMのPolicy
○ NodeGroupにつけるものと同じもの
CloudFormation使ってやっていることは主に4つ
Slide 24
Slide 24 text
インストール編
24
● EventBridgeのルール
○ EC2の中断を監視し、SQSにルーティングする
● SQS Queue
○ 中断通知をKarpenterに送信する
👉これらのCloudFormationでの記載をTerraformのコードに書き換えていった
結構⼤変 IAMで278L、EventBridgeで60L、SQSが45L
AIでいい感じに…はできなかったので変換するようなソリューションがあればいいなぁ
CloudFormation使ってやっていることは主に4つ
Slide 25
Slide 25 text
インストール編
25
ClusterConfigを作っていろいろやっている(⼀部抜粋)
eksctlコマンドでクラスタを作成している
eksctl create cluster -f - <
Slide 26
Slide 26 text
インストール編
26
● EKS Pod Identityを使う設定
○ Clusterごとにユニークな K8s role を作って Karpenter ControllerのIAM roleと紐づける
○ SQSを⽤いた中断通知に使っている模様
○ このために EKS アドオンの Pod Identity Agentを⼊れている
👉これはTerraformコードにはしなかった(eksctlコマンドで⼊れた)
● IAM Roleに⾃動でEKSアドオンバージョンなどのタグが付くのでterraform 管
理に向かないと判断
eksctlコマンドでやっている設定は主に3つ
% eksctl create podidentityassociation
Slide 27
Slide 27 text
インストール編
27
● aws-auth ComfigMapへの設定
○ IAM RoleとK8s RBACの紐付け(IAM Identity Mapping)
👉すでにConfigMapがコード管理されていたので挿⼊した
● Karpenter Pod配置⽤のNodeGroupの作成
○ KarpenterのPod⾃体はKarpenterではなくてNodeGroupで管理する
👉Terraformコードで管理
eksctlコマンドでやっている設定は主に3つ
Slide 28
Slide 28 text
インストール編
28
helmインストール
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter
--version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}"
--create-namespace \
--set "settings.clusterName=${CLUSTER_NAME}" \
--set "settings.interruptionQueue=${CLUSTER_NAME}" \
--set controller.resources.requests.cpu=1 \
--set controller.resources.requests.memory=1Gi \
--set controller.resources.limits.cpu=1 \
--set controller.resources.limits.memory=1Gi \
--wait
● ここまでの設定がちゃーんとされていれば起動する
Slide 29
Slide 29 text
インストール編
29
helmインストール
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter
--version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}"
--create-namespace \
--set "settings.clusterName=${CLUSTER_NAME}" \
--set "settings.interruptionQueue=${CLUSTER_NAME}" \
--set controller.resources.requests.cpu=1 \
--set controller.resources.requests.memory=1Gi \
--set controller.resources.limits.cpu=1 \
--set controller.resources.limits.memory=1Gi \
--wait
👈👈必要
● トラブルシューティングでinterruptionQueueの設定を抜くと起動する…とコミュニ
ティで書かれているがSQSを使ったspotインスタンスの中断制御が動かなくなる
● ちゃんとIAMの設定をしましょう
Slide 30
Slide 30 text
インストール編
30
helmインストール(CRD)
helm upgrade --install karpenter-crd
oci://public.ecr.aws/karpenter/karpenter-crd --version x.y.z --namespace
"${KARPENTER_NAMESPACE}" --create-namespace
● バージョンアップグレードの場合はCRDを別途helm upgradeしないといけない
Slide 31
Slide 31 text
インストール編
31
● 0.X →1.X へはCRD Conversion Webhookがうまく動かない
○ 結局クリーンインストールした
● とはいえクリーンインストールも気をつけることはある
○ 旧版のCRD(nodepool, ec2nodeclass)のリソースを消してからKarpenterを消す
○ リソースが残っていると新版のインストール時にこける→バージョンの切り戻し
○ サービス運⽤中のクラスタでKarpenterが動かない期間が⻑いと肝を冷やす
○ 1.1.X 以上のバージョンだと破壊的な変更はないので楽だろう
■ つまりこのつまづきは今は発⽣しにくいと思う
つまづきポイント
Slide 32
Slide 32 text
インストール編
32
● とにかくIAMの設定が多い！！！
○ 少しでも間違えると当たり前だけれども起動しなかったりする
○ Terraformへの変換もれで起動しないことはよくあった
○ CloudFormationに抵抗がないならそのほうがラクではある
● Cluster Autoscalerからのマイグレーションはドキュメントにあるが、クリーンイン
ストール⼿順と⽐べると抜けている情報がある……
○ SQSの中断制御周りの情報がない
○ 初⾒殺し
○ helm installでエラーになる
○ SQS、CloudWatchの設定は”Getting Started with Karpenter”を参照する
つまづきポイント
Slide 33
Slide 33 text
インストール編
33
● CAとKarpenterが同時に動いている状態⾃体は設定に重複がなければ問題はない
● CAの設定からまずはtagやtaintの設定があるノードグループを抜く
● tagやtaintがついているノードグループのノード数を0にする
● PodがevictされKarpenterでノードが作成され始める
● うまくいったらCAを消す(replica=0にするなど)
● tagやtaintのついていないノードグループのノード数を0にする
● KarpenterですべてのPodをプロビジョニングしている状態になる
Cluster Autoscalerからのインプレースな移⾏の戦略
いきなりすべてを移行するのではなく、 ノードグループ単位の移行 がおすすめ
Slide 34
Slide 34 text
インストール編
34
● Karpenterはインストール前にIAM、SQS、CloudWatch Alarm、EventBridgeの設
定、Pod Identity、aws-auth ComfigMapへの設定が必要
● CloudFormationを使うのが楽だがTerraformでも代替できる
● helmでインストールする。アップグレードの際は別途CRDのhelmインストールも
必要
● ClusterAutoscalerから切り替える際はノードグループ単位で作業するとサービス継
続しながらでも切り替えやすい
インストール編まとめ
Slide 35
Slide 35 text
3. Karpenter運⽤編
35
Slide 36
Slide 36 text
運⽤編
36
Karpenterの基本的なCustom Resourceは以下
● NodeClass
○ 以前(v0.33)までは node Templateという名前だった
○ ノードが起動するためのuserdataを定義
● NodePool
○ ノードに付与するtag、taint、どのNodeClassを使うか、どのインスタンスタイプを使う
かを定義
Karpenterのしくみ
Slide 37
Slide 37 text
運⽤編
37
⾃分はひとつの「default」NodeClassを作って、複数のNodePoolが参照する形に
Karpenterのしくみ
% kubectl get ec2nodeclass
NAME READY AGE
default True 27d
% kubectl get nodepool
NAME NODECLASS NODES READY AGE
arm64-default default 25 True 27d
arm64-monitor default 2 True 27d
arm64-on-datadog default 5 True 27d
multi-default default 2 True 27d
multi-monitor default 0 True 27d
multi-on-datadog default 0 True 27d
ノードが起動するための userdataを定義
参照するNodeClassはひとつのみ
Slide 38
Slide 38 text
運⽤編
38
● AL2023 を元にしたcustom AMIを別途作成し、使っている
● AMIは特定のタグがついているものの最新版を取ってくる
○ ベストプラクティスではないが⾃動で更新されて便利(後述)
NodeClass(1)
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2023
amiSelectorTerms:
- tags:
role: k8s
Slide 39
Slide 39 text
運⽤編
39
● ストレージタイプはgp3
● httpPutResponseHopLimit
○ インスタンスのメタデータを取得できるホップ数
○ これを1->2にしないと ALBC などで外からMetadataを参照できない
NodeClass(2)
blockDeviceMappings:
- deviceName: /dev/xvda
ebs:
volumeSize: 80Gi
volumeType: gp3
metadataOptions:
httpPutResponseHopLimit: 2 # for AWS Load Balancer Controller (IMDSv2)
Slide 40
Slide 40 text
運⽤編
40
● userdata
○ 社内セキュリティ要件でWazuhを⼊れている
○ ssm get-parameterは……
NodeClass(3)
--//
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
PARAM_NAME="/eks/wazuh-agent-auth-password"
AGENT_AUTH_PASSWORD=$(aws ssm get-parameter --name "$PARAM_NAME"
--with-decryption --query "Parameter.Value" --output text)
/var/ossec/bin/agent-auth -m wazuh.pepabo.com -P $AGENT_AUTH_PASSWORD -G minne
systemctl restart wazuh-agent
Slide 41
Slide 41 text
運⽤編
41
● userdata
○ spegel
○ コンテナレジストリのミラーをノード分散で作る。便利。
NodeClass(4)
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
sed -i '/\[plugins."io.containerd.grpc.v1.cri".registry\]/!b;n;cconfig_path =
"/etc/containerd/registries"' /etc/containerd/config.toml
sed -i '/discard_unpacked_layers = true/s/true/false/'
/etc/containerd/config.toml
systemctl daemon-reload
systemctl restart containerd
Slide 42
Slide 42 text
運⽤編
42
● ノードに付与するtag、taint、どのNodeClassを使うか、どのインスタンスタイプ
を使うかといった条件を定義するもの
● ⾃分はこうした：
○ weightが20のnodepoolの定義を参照して、当てはまらなければweight10のnodepoolの
定義を使う
NodePool
% kubectl get nodepool -o wide
NAME NODECLASS NODES READY AGE WEIGHT CPU MEMORY
arm64-default default 78 True 30d 20 412 2907533476Ki
multi-default default 17 True 30d 10 76 517494820Ki
Slide 43
Slide 43 text
運⽤編
43
● arm64-default
○ arm64のspotインスタンスを選択する設定
● multi-default
○ arm64/x86_64のon-demand/spotインスタンスから選択する設定
○ spotインスタンスを優先し、取得できなければon-demandを取得する動きをする
○ karpenterの特徴であり、便利な点
NodePoolはこう運⽤しています
% kubectl get nodepool -o wide
NAME NODECLASS NODES READY AGE WEIGHT CPU MEMORY
arm64-default default 78 True 30d 20 412 2907533476Ki
multi-default default 17 True 30d 10 76 517494820Ki
Slide 44
Slide 44 text
運⽤編
44
NodePool運⽤例 - arm64-default
requirements:
- key: kubernetes.io/arch
operator: In
values: ["arm64"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"]
- key: karpenter.k8s.aws/instance-family
operator: In
values: ["c7g","m7g","r7g","c6g","m6g","r6g"]
weight: 20
Slide 45
Slide 45 text
運⽤編
45
NodePool運⽤例 - multi-default
requirements:
- key: kubernetes.io/arch
operator: In
values: ["arm64","amd64"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot","on-demand"]
- key: karpenter.k8s.aws/instance-family
operator: In
values: ["c7i","m7i","r7i","c7g","m7g","r7g",
"c6i","m6i","r6i","c6g","m6g","r6g"]
weight: 10
Slide 46
Slide 46 text
運⽤編
46
Pod側ではNodeSelectorでspot/on-demandを指定できる
nodeSelector:
kubernetes.io/arch: "arm64"
karpenter.sh/capacity-type: "on-demand"
● NodePoolがspot/on-demand両⽅を許容していても、Pod側のNodeSelector
でon-demandのみを指定できたりする
● NodeGroupのようにノード側でtaintを指定しなくていいので楽
● Jobなど途中終了してほしくないもので活⽤すると便利
Slide 47
Slide 47 text
運⽤編
47
● Karpenterの⽬⽟機能！！
● クラスター内のノードを⾃動的に管理‧最適化
● ちゃんとpodをdrainしてからノードを終了する
● disruptionが発⽣する要因は主に4つ
○ Consolidation …使っていないノードを統合する
○ Drifted …古い設定のノードを終了する
■ NodeClassを更新した
■ amiのバージョンが更新された
○ Expiration …NodeClassで設定した起動期間を過ぎた
○ Interruption…spotインスタンスの中断による終了
NodePool - disruption(中断制御)
Slide 48
Slide 48 text
運⽤編
48
NodePool - disruptionは柔軟な設定ができる(ドキュメント例)
disruption:
budgets:
- nodes: “0”
schedule: "0 9 * * mon-fri"
duration: 8h
reasons:
- Drifted
- Underutilized
- nodes: "100%"
reasons:
- Empty
- nodes: "10%"
reasons:
- Drifted
- Underutilized
● 月-金の9時-17時はノード統合とノード最
新化はしない
● 空のノードはどの時間帯でも即終了させ
る
● 月-金の9時-5時以外のすべての時間帯
で、ノード統合とノード最新化はノード全
体の10%ずつおこなう
ノード統合はけっこう激しく動く特性がある。その
ためデイタイムは避ける設定にしている例
Slide 49
Slide 49 text
運⽤編
49
NodePool - disruptionで⾃分が⾏き着いたのはシンプルな設定
disruption:
budgets:
- nodes: “1”
● どの時間帯でもノード統合、ノード最新
化、空のノード終了を実行する
● 1ノードずつ実行する
これで十分！
※クラスタの規模によって調整は必要
Slide 50
Slide 50 text
運⽤編
50
NodePool - Spotインスタンスを使うならdisruptionは⼊れよう
● EC2インスタンスの料⾦が上昇し続ける現象が発⽣🤔
Slide 51
Slide 51 text
運⽤編
51
NodePool - Spotインスタンスを使うならdisruptionは⼊れよう
● EC2インスタンスの料⾦が上昇し続ける現象が発⽣🤔
● このとき、Spot優先で取得できなかったらon-demandを使う設定にしていた
● Spotインスタンスの終了の契機で、⽣え変わるインスタンスがSpotかon-demand
かが選択される
● on-demandインスタンスは⾃発的に終了しないため徐々に増え続けていたことが
原因
Slide 52
Slide 52 text
運⽤編
52
NodePool - Spotインスタンスを使うならdisruptionは⼊れよう
● disruptionを設定することでノード統合によるon-demandインスタンスが適切に終
了するようになった
Slide 53
Slide 53 text
運⽤編
53
● 結論：あまりPod側で凝ったスケジュールの設定はしないほうがよい
● deploymentへのAvailability Zone 分散 と Host分散の同時設定はオススメしない
避けた⽅がよい設定(1)
affinity:
podAntiAffinity:
requiredDuringScheduling
IgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- minne-app
topologyKey: "kubernetes.io/hostname"
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: minne-app
Slide 54
Slide 54 text
運⽤編
54
● 結論：あまりPod側で凝ったスケジュールの設定はしないほうがよい
● deploymentへのAvailability Zone 分散 と Host分散の同時設定はオススメしない
● リソースのrequestが異なる複数のdeploymentで設定すると、AZ分散とhost分散
を両⽴できる最適な構成が実現できず、disruptionによるノードの削除→ノードの
作成を繰り返す状態になってしまう
避けた⽅がよい設定(1)
Slide 55
Slide 55 text
運⽤編
55
● 結論：Podを削除するアプリケーションは組み合わせないほうがよい
● Deschedulerとの同時設定はオススメしない
○ Podの⾃動削除とノードのdisruptionで設定が複雑化する
○ disruptionによるノードの削除→ノードの作成を繰り返す状態になってしまう
避けた⽅がよい設定(2)
Slide 56
Slide 56 text
運⽤編
56
● Karpenterはノードの作成と削除が⾼頻度で⾏われる傾向にある
● そのためIPアドレス取得のAPIコールが多すぎるのが原因？
○ minneで確認してみると1時間に186回
● CNIプラグインには⼀度に/28でIPアドレスを取得できるprefixモードがある
● インプレースな切り替えに挑戦してみたがうまく切り替わらず断念……
課題：NodeやPodのIPアドレスの取得に時間がかかることがある
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup
network for sandbox
"efa491cb046eadb3e2799b3eb4f47293c2ed7c749fcc21cfb9903c62cf484791": plugin
type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP
address to container
Slide 57
Slide 57 text
運⽤編
57
● Karpenterには主に NodeClass,NodePoolというカスタムリソースがある
● NodeClassはuserdataの設定など、NodePoolはNodeで使うインスタンスタイプの
指定やタグの設定をする
● Pod側でもspot, on-demandをNodeSelectorで指定できる
● disruption(中断制御)はぜひ設定する
● AZ分散とhost分散を組み合わせたり、他のPod削除するソフトウェアと組み合わせ
ると管理が複雑化するため避ける
運⽤編まとめ
Slide 58
Slide 58 text
運⽤編
58
● Karpenterは「導⼊はちょっと複雑、導⼊できたら管理は簡単」
● Spotインスタンスでのコスト最適化がこれひとつで完結する
● 運⽤からEC2インスタンスのコスト最適化が⼿離れする感覚が⾮常に良い
● まだまだまとまったノウハウがアウトプットされていない印象がある
○ 特に⽇本語は！！
● 今のAWSの戦略をみると今後のスタンダードになることは間違いないので、気に
なっている⼈の参考になれば幸いです
全体を通して
Slide 59
Slide 59 text
GMOペパボは積極採⽤中です！
59