SlideShare uma empresa Scribd logo
1 de 16
Karpenterで君だけの最強のオートスケーリングを実装しよう
© 2021 3-shake Inc. 2
自己紹介
- 株式会社スリーシェイク Sreake事業部
- 業務: SREとしてインフラ扱ったり、コード読み書きしたり
- Kubernetes周辺は個人的趣味もあり興味持って触っています
- 雪がどっぷり降る地域に住んでいます
- 趣味: 料理、お酒
永瀬滉平
© 2021 3-shake Inc. 3
今回のテーマは
自動化ツール
クラスター”オート”スケーラー
k8sのノード管理を”自動化”するKarpenterと
いうツールについてのお話しです
© 2021 3-shake Inc. 4
Karpenter is
オープンソースのクラスターオートスケーラーです。
目的はCluster Autoscalerと同様で、k8sのノードが足りなくなったら足して、不
要になったら削除するというのを実現します。
【特徴】
- 柔軟なリソース選択
- スケジュールできないpod全体でどれだけリソースが必要なのかを計算した上で、
最適なインスタンスタイプをその都度選択してくれます
- ASGのようなノードグループを使わず、Karpenterによってノードの選定・起動・削除が行われます
参照:https://karpenter.sh/
© 2021 3-shake Inc. 5
Karpenter is
参照:https://karpenter.sh/
© 2021 3-shake Inc. 6
Karpenter is
$ k get all -n karpenter
NAME READY STATUS RESTARTS AGE
pod/karpenter-7c4bd8bdd7-7mcvt 2/2 Running 0 2d21h
pod/karpenter-7c4bd8bdd7-b585k 2/2 Running 0 2d11h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/karpenter ClusterIP 172.20.30.137 <none> 8080/TCP,443/TCP 13d
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/karpenter 2/2 2 2 13d
NAME DESIRED CURRENT READY AGE
replicaset.apps/karpenter-7c4bd8bdd7 2 2 2 13d
$ k get crd | grep karpenter
awsnodetemplates.karpenter.k8s.aws 2022-07-21T07:39:07Z
provisioners.karpenter.sh 2022-07-21T07:39:07Z
$ k get mutatingwebhookconfigurations.admissionregistration.k8s.io | grep karpenter
defaulting.webhook.provisioners.karpenter.sh 1 13d
$ k get validatingwebhookconfigurations.admissionregistration.k8s.io | grep karpenter
validation.webhook.config.karpenter.sh 1 13d
validation.webhook.provisioners.karpenter.sh 1 13d
karpenterのPodには2つのコンテナが含まれている
- webhook: カスタムリソースの変更を検知・検証
- controller: ノード追加・削除などの処理を実施
CRD
- awsnodetemplates: ノードを追加する際に使用する
テンプレートを設定する際に使用
- provisioners: ノードの管理にあたって設定する際に
使用
© 2021 3-shake Inc. 7
Karpenter is
karpenterのミソとなるCustom Resourceである、Provisioner
ノード管理に関する設定を行うリソースです。
例えば以下のような設定ができます
- ノードに付与するラベル、taints
- インスタンスタイプの指定
- ノードのTTL指定
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: app1
spec:
labels:
workload: "app1"
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: [ "spot" ]
- key: "node.kubernetes.io/instance-type"
operator: NotIn
values: [ "m6g.16xlarge", "m6gd.16xlarge", "r6g.16xlarge", "r6gd.16xlarge" ]
limits:
resources:
cpu: 50
memory: 500Gi
provider:
subnetSelector:
karpenter.sh/discovery: "cluster-name"
securityGroupSelector:
karpenter.sh/discovery: "cluster-name"
tags:
karpenter.sh/discovery: "cluster-name"
ttlSecondsAfterEmpty: 30
© 2021 3-shake Inc. 8
今回のトピックは
Karpenterを実運用していくにあたって、
「ここは押さえておこう」というポイントをお話しします
【目次】
1. nodeSelector, taints/tolerationsを使ってノードグループを分ける
1. KarpenterのアプリPodを分散配置する
1. 不必要・必要以上なインスタンスタイプを除外する
© 2021 3-shake Inc. 9
題材のマニフェスト
githubにあげていますので、適宜参照していただければと思います。
(よろしければ手元でもぜひ試してみてください)
リポジトリ: https://github.com/k-ngs/karpenter-test
© 2021 3-shake Inc. 10
- アプリの性質や可用性などによってPodを配置するノードを適切
に選択するため、Provisionerでlabelやtaintを付与します
- CAの場合だとノードグループを分けて対応していたものを
Provisioner(Kubernetesリソース)で実現します
※立ち上げようとするpodが複数のProvisionerに当てはまること
がないように設計します
その1 nodeSelector, taints/tolerationsを使ってノードグループを分ける
© 2021 3-shake Inc. 11
その1 nodeSelector, taints/tolerationsを使ってノードグループを分ける
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: app1
spec:
labels:
workload: "app1"
…
…
apiVersion: apps/v1
kind: Deployment
metadata:
name: app1
spec:
…
spec:
nodeSelector:
workload: "app1"
…
…
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: app2
spec:
taints:
- key: workload
value: "app2"
operator: "Exists"
effect: NoSchedule
…
…
apiVersion: apps/v1
kind: Deployment
metadata:
name: app2
spec:
…
spec:
tolerations:
- key: "workload"
value: "app2"
effect: "NoSchedule"
…
nodeSelectorの例
taints/tolerationsの例
© 2021 3-shake Inc. 12
その1 nodeSelector, taintを使ってノードグループを分ける
Q.nodeSelectorやTolerationsなどの条件に合うProvisionerがない場合は?
A.ノード自体が追加されません
KarpenterがPod配置の関わる条件を読み取って、Provisionerとの照らし合
わせを行っています
↓ちなみにこんなログが出力されます。
ERROR controller.provisioning Could not schedule pod, incompatible with provisioner "default",
incompatible requirements, key workload, [application] not in [default]
{"commit": "062a029", "pod": "karpenter-test/karpenter-test-5d98488ddc-7nfgm"}
© 2021 3-shake Inc. 13
その2 KarpenterのアプリPodを分散配置する
- レプリカ数を増やし、AZなどを元に分散配置してある程度の可用性を確保する
- https://github.com/k-ngs/karpenter-test/blob/main/manifests/values.yaml#L16
- 公式のhelm chartでは↑のように、replicasという変数で設定できる
- デフォルトだとtopologySpreadConstraintsがtopology.kubernetes.io/zoneに設定されている
(AZでの分散配置)
Q.KarpenterのPodが配置されているノードが落ちた場合はどうなるの?
A.Podが落ちていることになるので、ノードの追加・削除が行われなくなります
© 2021 3-shake Inc. 14
その3 不必要・必要以上なインスタンスタイプを除外する
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: app-1
spec:
labels:
workload: "app-1"
requirements:
- key: "node.kubernetes.io/instance-type"
operator: NotIn
values: [ "m6g.16xlarge", "m6gd.16xlarge", "r6g.16xlarge", "r6gd.16xlarge" ]
…
Gravitonプロセッサ搭載の大きな
インスタンスを禁止する例
参照:https://aws.github.io/aws-eks-best-practices/karpenter/#exclude-instance-types-that-do-not-fit-your-workload
- Karpenterを使うメリットを最大限生かすため、ブラックリスト方式でインスタンスタイプをチョイス
するのが望ましいと考えます
- スポットインスタンスで運用する場合は可用性の観点から重要度が増します(望ましいインスタ
ンスタイプ確保ができない場合に代替となるインスタンスタイプがなくなるため)
© 2021 3-shake Inc. 15
まとめ
1. nodeSelector, taints/tolerationsを使ってノードグループを分ける
1. KarpenterのアプリPodを分散配置する
1. 不必要・必要以上なインスタンスタイプを除外する
インスタンスタイプをその都度柔軟に選択できるというのは、とても画期的でありクラウド
でKubernetesを使うという点で大きな意味があることだと思います。
ぜひこれを機にKarpenterを検証・導入して、
君だけの最強のクラスターオートスケーラーを実現しよう!
Thank you

Mais conteúdo relacionado

Mais procurados

CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
Katsuya Yamaguchi
 
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
Hibino Hisashi
 

Mais procurados (20)

20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #1320210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
20210127 今日から始めるイベントドリブンアーキテクチャ AWS Expert Online #13
 
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話
 
Ingress on Azure Kubernetes Service
Ingress on Azure Kubernetes ServiceIngress on Azure Kubernetes Service
Ingress on Azure Kubernetes Service
 
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
忙しい人の5分で分かるMesos入門 - Mesos って何だ?忙しい人の5分で分かるMesos入門 - Mesos って何だ?
忙しい人の5分で分かるMesos入門 - Mesos って何だ?
 
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮
 
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのことマルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
AWS Well-Architected Security とベストプラクティス
AWS Well-Architected Security とベストプラクティスAWS Well-Architected Security とベストプラクティス
AWS Well-Architected Security とベストプラクティス
 
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
Knative Eventing 入門(Kubernetes Novice Tokyo #11 発表資料)
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれやMySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれや
 
Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例Amazon EKS によるスマホゲームのバックエンド運用事例
Amazon EKS によるスマホゲームのバックエンド運用事例
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
JCBの Payment as a Service 実現にむけたゼロベースの組織変革とテクニカル・イネーブラー(NTTデータ テクノロジーカンファレンス ...
 
20200212 AWS Black Belt Online Seminar AWS Systems Manager
20200212 AWS Black Belt Online Seminar AWS Systems Manager20200212 AWS Black Belt Online Seminar AWS Systems Manager
20200212 AWS Black Belt Online Seminar AWS Systems Manager
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
Kubernetes環境に対する性能試験(Kubernetes Novice Tokyo #2 発表資料)
Kubernetes環境に対する性能試験(Kubernetes Novice Tokyo #2 発表資料)Kubernetes環境に対する性能試験(Kubernetes Novice Tokyo #2 発表資料)
Kubernetes環境に対する性能試験(Kubernetes Novice Tokyo #2 発表資料)
 
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
 
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
 
DevOps with Database on AWS
DevOps with Database on AWSDevOps with Database on AWS
DevOps with Database on AWS
 

Semelhante a Karpenterで君だけの最強のオートスケーリングを実装しよう

Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストール
Yasuhiro Arai
 
最近良く聞く Kubernetes を体験してみた イントロ + 活用編
最近良く聞く Kubernetes を体験してみた イントロ + 活用編最近良く聞く Kubernetes を体験してみた イントロ + 活用編
最近良く聞く Kubernetes を体験してみた イントロ + 活用編
Fuminobu Takeyama
 

Semelhante a Karpenterで君だけの最強のオートスケーリングを実装しよう (20)

SparkやBigQueryなどを用いた モバイルゲーム分析環境
SparkやBigQueryなどを用いたモバイルゲーム分析環境SparkやBigQueryなどを用いたモバイルゲーム分析環境
SparkやBigQueryなどを用いた モバイルゲーム分析環境
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
 
Private Azure Kubernetes Service cluster を触ってみよう♪
Private Azure Kubernetes Service cluster を触ってみよう♪Private Azure Kubernetes Service cluster を触ってみよう♪
Private Azure Kubernetes Service cluster を触ってみよう♪
 
OCP Meetup Tokyo #05 ECK on OCP
OCP Meetup Tokyo #05 ECK on OCPOCP Meetup Tokyo #05 ECK on OCP
OCP Meetup Tokyo #05 ECK on OCP
 
MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜 #cwt2015
MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜 #cwt2015MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜 #cwt2015
MapReduceを置き換えるSpark 〜HadoopとSparkの統合〜 #cwt2015
 
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
Kubernetes + containerd で cgroup v2 に移行したら "failed to create fsnotify watcher...
 
Dockerセキュリティ: 今すぐ役に立つテクニックから,次世代技術まで
 Dockerセキュリティ: 今すぐ役に立つテクニックから,次世代技術まで Dockerセキュリティ: 今すぐ役に立つテクニックから,次世代技術まで
Dockerセキュリティ: 今すぐ役に立つテクニックから,次世代技術まで
 
Building andobservingcloudnativeappliactionusingazure elastic-terraform
Building andobservingcloudnativeappliactionusingazure elastic-terraformBuilding andobservingcloudnativeappliactionusingazure elastic-terraform
Building andobservingcloudnativeappliactionusingazure elastic-terraform
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
Apache cloudstack4.0インストール
Apache cloudstack4.0インストールApache cloudstack4.0インストール
Apache cloudstack4.0インストール
 
サイバーエージェント様 導入事例:OpenStack Fast Track – 若葉マークStackerのStacker教習所 - OpenStack最新...
サイバーエージェント様 導入事例:OpenStack Fast Track – 若葉マークStackerのStacker教習所 - OpenStack最新...サイバーエージェント様 導入事例:OpenStack Fast Track – 若葉マークStackerのStacker教習所 - OpenStack最新...
サイバーエージェント様 導入事例:OpenStack Fast Track – 若葉マークStackerのStacker教習所 - OpenStack最新...
 
半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)半日でわかる コンテナー技術 (応用編)
半日でわかる コンテナー技術 (応用編)
 
最近良く聞く Kubernetes を体験してみた イントロ + 活用編
最近良く聞く Kubernetes を体験してみた イントロ + 活用編最近良く聞く Kubernetes を体験してみた イントロ + 活用編
最近良く聞く Kubernetes を体験してみた イントロ + 活用編
 
インフラ野郎AzureチームProX
インフラ野郎AzureチームProXインフラ野郎AzureチームProX
インフラ野郎AzureチームProX
 
G-Tech2015 Hadoop/Sparkを中核としたビッグデータ基盤_20151006
G-Tech2015 Hadoop/Sparkを中核としたビッグデータ基盤_20151006G-Tech2015 Hadoop/Sparkを中核としたビッグデータ基盤_20151006
G-Tech2015 Hadoop/Sparkを中核としたビッグデータ基盤_20151006
 
OpenBSD/luna88k yearly progress report (from May 2017 to May 2018)
OpenBSD/luna88k yearly progress report (from May 2017 to May 2018)OpenBSD/luna88k yearly progress report (from May 2017 to May 2018)
OpenBSD/luna88k yearly progress report (from May 2017 to May 2018)
 
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
Kubernetes、Flannel、CNIでWindows Container ClusterオーケストレーションKubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
Kubernetes、Flannel、CNIでWindows Container Clusterオーケストレーション
 
TripleOの光と闇
TripleOの光と闇TripleOの光と闇
TripleOの光と闇
 
Introduction to Magnum (JP)
Introduction to Magnum (JP)Introduction to Magnum (JP)
Introduction to Magnum (JP)
 

Karpenterで君だけの最強のオートスケーリングを実装しよう

  • 2. © 2021 3-shake Inc. 2 自己紹介 - 株式会社スリーシェイク Sreake事業部 - 業務: SREとしてインフラ扱ったり、コード読み書きしたり - Kubernetes周辺は個人的趣味もあり興味持って触っています - 雪がどっぷり降る地域に住んでいます - 趣味: 料理、お酒 永瀬滉平
  • 3. © 2021 3-shake Inc. 3 今回のテーマは 自動化ツール クラスター”オート”スケーラー k8sのノード管理を”自動化”するKarpenterと いうツールについてのお話しです
  • 4. © 2021 3-shake Inc. 4 Karpenter is オープンソースのクラスターオートスケーラーです。 目的はCluster Autoscalerと同様で、k8sのノードが足りなくなったら足して、不 要になったら削除するというのを実現します。 【特徴】 - 柔軟なリソース選択 - スケジュールできないpod全体でどれだけリソースが必要なのかを計算した上で、 最適なインスタンスタイプをその都度選択してくれます - ASGのようなノードグループを使わず、Karpenterによってノードの選定・起動・削除が行われます 参照:https://karpenter.sh/
  • 5. © 2021 3-shake Inc. 5 Karpenter is 参照:https://karpenter.sh/
  • 6. © 2021 3-shake Inc. 6 Karpenter is $ k get all -n karpenter NAME READY STATUS RESTARTS AGE pod/karpenter-7c4bd8bdd7-7mcvt 2/2 Running 0 2d21h pod/karpenter-7c4bd8bdd7-b585k 2/2 Running 0 2d11h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/karpenter ClusterIP 172.20.30.137 <none> 8080/TCP,443/TCP 13d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/karpenter 2/2 2 2 13d NAME DESIRED CURRENT READY AGE replicaset.apps/karpenter-7c4bd8bdd7 2 2 2 13d $ k get crd | grep karpenter awsnodetemplates.karpenter.k8s.aws 2022-07-21T07:39:07Z provisioners.karpenter.sh 2022-07-21T07:39:07Z $ k get mutatingwebhookconfigurations.admissionregistration.k8s.io | grep karpenter defaulting.webhook.provisioners.karpenter.sh 1 13d $ k get validatingwebhookconfigurations.admissionregistration.k8s.io | grep karpenter validation.webhook.config.karpenter.sh 1 13d validation.webhook.provisioners.karpenter.sh 1 13d karpenterのPodには2つのコンテナが含まれている - webhook: カスタムリソースの変更を検知・検証 - controller: ノード追加・削除などの処理を実施 CRD - awsnodetemplates: ノードを追加する際に使用する テンプレートを設定する際に使用 - provisioners: ノードの管理にあたって設定する際に 使用
  • 7. © 2021 3-shake Inc. 7 Karpenter is karpenterのミソとなるCustom Resourceである、Provisioner ノード管理に関する設定を行うリソースです。 例えば以下のような設定ができます - ノードに付与するラベル、taints - インスタンスタイプの指定 - ノードのTTL指定 apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: app1 spec: labels: workload: "app1" requirements: - key: karpenter.sh/capacity-type operator: In values: [ "spot" ] - key: "node.kubernetes.io/instance-type" operator: NotIn values: [ "m6g.16xlarge", "m6gd.16xlarge", "r6g.16xlarge", "r6gd.16xlarge" ] limits: resources: cpu: 50 memory: 500Gi provider: subnetSelector: karpenter.sh/discovery: "cluster-name" securityGroupSelector: karpenter.sh/discovery: "cluster-name" tags: karpenter.sh/discovery: "cluster-name" ttlSecondsAfterEmpty: 30
  • 8. © 2021 3-shake Inc. 8 今回のトピックは Karpenterを実運用していくにあたって、 「ここは押さえておこう」というポイントをお話しします 【目次】 1. nodeSelector, taints/tolerationsを使ってノードグループを分ける 1. KarpenterのアプリPodを分散配置する 1. 不必要・必要以上なインスタンスタイプを除外する
  • 9. © 2021 3-shake Inc. 9 題材のマニフェスト githubにあげていますので、適宜参照していただければと思います。 (よろしければ手元でもぜひ試してみてください) リポジトリ: https://github.com/k-ngs/karpenter-test
  • 10. © 2021 3-shake Inc. 10 - アプリの性質や可用性などによってPodを配置するノードを適切 に選択するため、Provisionerでlabelやtaintを付与します - CAの場合だとノードグループを分けて対応していたものを Provisioner(Kubernetesリソース)で実現します ※立ち上げようとするpodが複数のProvisionerに当てはまること がないように設計します その1 nodeSelector, taints/tolerationsを使ってノードグループを分ける
  • 11. © 2021 3-shake Inc. 11 その1 nodeSelector, taints/tolerationsを使ってノードグループを分ける apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: app1 spec: labels: workload: "app1" … … apiVersion: apps/v1 kind: Deployment metadata: name: app1 spec: … spec: nodeSelector: workload: "app1" … … apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: app2 spec: taints: - key: workload value: "app2" operator: "Exists" effect: NoSchedule … … apiVersion: apps/v1 kind: Deployment metadata: name: app2 spec: … spec: tolerations: - key: "workload" value: "app2" effect: "NoSchedule" … nodeSelectorの例 taints/tolerationsの例
  • 12. © 2021 3-shake Inc. 12 その1 nodeSelector, taintを使ってノードグループを分ける Q.nodeSelectorやTolerationsなどの条件に合うProvisionerがない場合は? A.ノード自体が追加されません KarpenterがPod配置の関わる条件を読み取って、Provisionerとの照らし合 わせを行っています ↓ちなみにこんなログが出力されます。 ERROR controller.provisioning Could not schedule pod, incompatible with provisioner "default", incompatible requirements, key workload, [application] not in [default] {"commit": "062a029", "pod": "karpenter-test/karpenter-test-5d98488ddc-7nfgm"}
  • 13. © 2021 3-shake Inc. 13 その2 KarpenterのアプリPodを分散配置する - レプリカ数を増やし、AZなどを元に分散配置してある程度の可用性を確保する - https://github.com/k-ngs/karpenter-test/blob/main/manifests/values.yaml#L16 - 公式のhelm chartでは↑のように、replicasという変数で設定できる - デフォルトだとtopologySpreadConstraintsがtopology.kubernetes.io/zoneに設定されている (AZでの分散配置) Q.KarpenterのPodが配置されているノードが落ちた場合はどうなるの? A.Podが落ちていることになるので、ノードの追加・削除が行われなくなります
  • 14. © 2021 3-shake Inc. 14 その3 不必要・必要以上なインスタンスタイプを除外する apiVersion: karpenter.sh/v1alpha5 kind: Provisioner metadata: name: app-1 spec: labels: workload: "app-1" requirements: - key: "node.kubernetes.io/instance-type" operator: NotIn values: [ "m6g.16xlarge", "m6gd.16xlarge", "r6g.16xlarge", "r6gd.16xlarge" ] … Gravitonプロセッサ搭載の大きな インスタンスを禁止する例 参照:https://aws.github.io/aws-eks-best-practices/karpenter/#exclude-instance-types-that-do-not-fit-your-workload - Karpenterを使うメリットを最大限生かすため、ブラックリスト方式でインスタンスタイプをチョイス するのが望ましいと考えます - スポットインスタンスで運用する場合は可用性の観点から重要度が増します(望ましいインスタ ンスタイプ確保ができない場合に代替となるインスタンスタイプがなくなるため)
  • 15. © 2021 3-shake Inc. 15 まとめ 1. nodeSelector, taints/tolerationsを使ってノードグループを分ける 1. KarpenterのアプリPodを分散配置する 1. 不必要・必要以上なインスタンスタイプを除外する インスタンスタイプをその都度柔軟に選択できるというのは、とても画期的でありクラウド でKubernetesを使うという点で大きな意味があることだと思います。 ぜひこれを機にKarpenterを検証・導入して、 君だけの最強のクラスターオートスケーラーを実現しよう!

Notas do Editor

  1. 今回のテーマが自動化ツールとのことでしたので、kubernetesのノード管理を自動化するKarpenterというツールについてお話しします。
  2. 目的は本家のCAと同様でkubernetesのノードが足りなくなったら足して、不要になったら削除します。
  3. PendingしているpodのなかでスケジュールできないpodをKarpenterが検知して、最適なノードをノードを
  4. 今回は題材となるマニフェストや設定例があります。 githubにあげていますので、適宜確認していただければと思います。
  5. nodeSelectorを用いて設定する例
  6. Karpenterの最も大きな特徴は必要なリソースに応じてダイナミックにノードを選択してくれることです。 ただし、Kubernetes上で動かすワークロードに適さないインスタンスをプロビジョニングされる可能性もありますので選択できるインスタンスタイプの幅をある程度制限してあげるようにしましょう。