EKS: マネージドKubernetes †
- Amazon EKS – マネージド Kubernetes サービス
- Architecture - Modular and Scalable Amazon EKS Architecture VPC設計の参考
- MultiAZととして、最低3AZ。AZが売り切れの場合があるので、予備として1AZ * 2 subnet(public, private)が良いのでは
- public subnetは/24, privateは/19等非対称かつ、private IPをたくさん使えるようにする必要がある(1 Pod = 1 IP, 1 EC2 x30 IP程予約する。)
- 1 EC2内に管理サービス用Podが複数起動するため、実サービス用Podを入れるとpod数が増える。小さいinstance typeでは実サービス用Podが数個しか置けない状況が発生するので向いてない。large以上が良さそう
- ネットワーク計算ツール・CIDR計算ツール | Softel labs
- 「/16」(最大IP: 65536) /19(IP 8192個)のsubnet 8個は広すぎて、VPC数が足りなくなる気がする。
- 「/17」(最大IP: 32768) /20(IP 4096個)のsubnet 8個
- 「/18」(最大IP: 16384) /21(IP 2048個)のsubnet 8個
- 「/19」(最大IP: 8192) /22(IP 1024個)のsubnet 8個
- 「/20」(最大IP: 4096) /23(IP 512個)のsubnet 8個
- 「/21」(最大IP: 2048) /24(IP 256個)のsubnet 8個 # 最低このくらい
トラブルシューティング †
Docker Hubのratelimit上限に達した場合 †
- 同一IPからのdocker pullに上限がある。EKS node group作り直し等すると、すぐに到達する場合がある
- AWSならECR publicに変更すると良さそう
- Memo/Docker#q7ee3a22
SPOTインスタンスの活用 †
- オンデマンドと比べて、SPOTインスタンスは-70%前後(2023-08時点)とかなり安い。その代わり、数分で終了する可能性がある
- AutoSalingGroupが、CPUコア数、メモリ等似たインスタンスタイプを要求する
- Amazon EC2 インスタンスタイプを選択する - Amazon EKS
特に多くの Daemonsets が存在する場合などは、一般的に、数少ない大型のインスタンスの使用が適しています。各インスタンスには API サーバーへの API コールが必要です。したがって、インスタンス数が多いほど、API サーバーのロードが高くなります。
料金:
- SPOTインスタンス: スポットインスタンスアドバイザー | AWS
- ON-DEMANDインスタンス:
- 2023-08, on-demand, ap-northeast-1 での月額費用
"t3a.large", 71.47 USD/month~
"t3.large", 79.42 USD/month~
"m6a.large", 81.47 USD/month~
"m6i.large", 90.52 USD/month~
"m6id.large", 111.91 USD/month~
"m6idn.large", 149.47 USD/month~
"m6in.large", 130.68 USD/month~
Cluster Autoscalerの設定で、「spot〜」から始まるEKS node groupを優先して使うようにする
例: SPOT対応、現行世代を探す。
- SPOTを多く使い、費用を削減するには、近しいスペックでなるべく多くのインスタンスタイプを列挙したい
- system系のpodがnode毎にインストールされるので、インスタンスタイプが小さいとpodに割り当てるメモリが不足して、無駄にインスタンス数が増える。AWSは大きいインスタンスタイプを推奨しているが、プロジェクトの最小に合わせて選ぶしかなさそう
- 「--burst-support true」 t2/t3系を入れる/入れない。CPUの利用時間に上限がある。CPU利用率が100%近い用途は向かない。開発/テスト環境向け
- 「--memory-min 3 --memory-max 4」と範囲で指定すると、対象が広がる。例：c4系が入ってくる
- 「--ena-support」t3, m5以上
- 「--deny-list 'd\.|n\.'」 d:高速なディスク, n:高速なネットワーク。デフォルトと比べて割高なのでオンデマンド用途で除外したい場合
- 「--allow-list '^[cmrt]'」c/m/r/t系を利用し、d3en.* 等除外したい場合
ec2-instance-selector \
--vcpus 2 \
--memory 4 \
--cpu-architecture x86_64 \
--gpus 0 \
--current-generation \
--usage-class spot \
--profile example \
--region ap-northeast-1
c5.large
c5a.large
c5d.large
c6a.large
c6i.large
c6id.large
c6in.large
t2.medium
t3.medium
t3a.medium
- 配列形式で出力: 以下をコマンドに追加
| xargs -i echo '"{}",'
記事:
terraformでの構築 †
private IPが枯渇する †
- /24のsubnetだと有効なIPは251個
- 1 EC2あたり複数のpodが稼働する
- 1 podあたり1 IP以上使用する。
- m5.xlargeだとデフォルトで30 IPくらいprivate subnet上に予約される
- public subnetのIPは余る
記事:
別CIDRを追加する:
- チュートリアル: カスタムネットワーキング - Amazon EKS
- EKS node-groupはdefault subnet(EKS クラスターと同じ)を指定する。new subnetではない。new subnetを指定するとnodeが「network plugin is not ready: cni config uninitialized」で起動しない
- EKS node用EC2はdefault subnet上に作成される
- pod用IPが複数new subnet上に確保される
- 例: プライベート IPv4 アドレス: defaut subnet: 1 IP、new subnet: 2 IP
- 例: セカンダリプライベート IPv4 アドレス: new subnet: 10 IP
- チュートリアルでは、新規node-groupを作り、古い方を消している。しかし、nodeが作り直されれば、古いnode-groupのままでもpodにnew subnetのIPが割り当てられた。
予約されるIP数を調整する:
IPv6で構成する:
EKS配下のEC2にName tagを付ける †
eksctlを使う場合:
terraformの場合:
モニタリング †
Fargate for EKS †
![[PukiWiki]](image/owl.png "[PukiWiki]")
