--- title: "GKE Autopilotを試してみた | grasys blog" url: "https://blog.grasys.io/post/shimichan/try_gke_autopilot/" description: "boom boom! Hello Cloud! どうも、しみちゃんでございます。 今日は、今話題のGKE Autopilotを試してみたので チュートリアルと使用感のご紹介をしたいと思います。 GKE Autopilot が 2021/2/25 にリリースされました。 記事: Introducing GKE Auto…" --- # GKE Autopilotを試してみた - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[shimichan](/authors/shimichan/) - 公開日：2021年3月9日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#autopilot](/tags/autopilot/)[#GKE](/tags/gke/) ![GKE Autopilotを試してみた](/_astro/og-image.DDSiu2Ny_XHpDd.webp) boom boom! Hello Cloud! どうも、しみちゃんでございます。 今日は、今話題のGKE Autopilotを試してみたので チュートリアルと使用感のご紹介をしたいと思います。 GKE Autopilot が 2021/2/25 にリリースされました。 記事: [Introducing GKE Autopilot: a revolution in managed Kubernetes](https://cloud.google.com/blog/ja/products/containers-kubernetes/introducing-gke-autopilot) ## GKE Autopilot とは? GKE の新たな操作・管理モードです。 今までのGKEの管理モード(標準モード)クラスタ・コントロールプレーンの管理に加え、Nodeの管理を良い感じにGoogle Cloud (GCP)が代わりに行ってくれると言うものです。 「GKEってなんやねん」って方は、まずは[こちら](https://cloud.google.com/kubernetes-engine)の公式を見ましょう。 ### とりあえずやってみよう、ということで 試してみました。 * * * ### 実際に作ってみる まずはクラスターを作りましょう。 1.Webコンソールからナビゲーションメニュー→ Kubernetes Engine のページへ移り、 \[作成\] ボタンを押します。 ![Google CloudコンソールでGKEクラスタの作成を開始する画面](/_astro/01-10-1-71a99e01.ZSJkdLZu_2w84AR.webp) 2.標準モードかAutopilotモードかを選択します。もちろんここでは Autopilot を選択します. ![GKEクラスタの作成モードでAutopilotを選択する画面](/_astro/02-11-14-aab20edc.B8yIvYA4_hTLma.webp) 3.クラスタ名とリージョンを指定し、デフォルトで \[作成\] ボタンを押します ![GKE Autopilotクラスタの名前とリージョンを設定する画面](/_astro/03-12-13-804x1024-8cca187b.93dwRHya_24sa5T.webp) 4.しばらく待って、こんな感じでクラスターが作成されればOK ![作成が完了したGKE Autopilotクラスタ](/_astro/04-13-12-1024x34-d9dc9de6.GbsmlKiu_Z25D9JA.webp) * * * #### 動かしてみる とても簡単にクラスターは作れたのではないでしょうか? 次は、実際に操作してみましょう！ ##### まずは接続から まずはクラスタのクレデンシャルを取得します。 1.作成したクラスタの一番右のボタンから\[接続\]を押します。 ![まずは接続からの画面（1）](/_astro/05-14-10-1024x138-6c646ff0.StjnOhvS_sHJmp.webp) 2.すると gcloud コマンドが出てくるので、コピーします ![まずは接続からの画面（2）](/_astro/06-15-11-1024x559-c6ed062d.CjpwO0Zk_1byJ22.webp) 3.コピーしたコマンドをターミナルから発行します。 Plain textcontent\_copy ``` # gcloud container clusters get-credentials shimziu-autopilot-1 --region asia-northeast1 --project PROJECT_NAME Fetching cluster endpoint and auth data. kubeconfig entry generated for shimziu-autopilot-1. ``` 4.どんな node があるのか見てみます Plain textcontent\_copy ``` # kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-shimziu-autopilot-1-default-pool-8cae60ca-201z Ready 7m45s v1.18.12-gke.1210 gk3-shimziu-autopilot-1-default-pool-f5dfb22d-9qtb Ready 7m48s v1.18.12-gke.1210 ``` 現在(2021/03時点)では 1.18.12 が適用されているようです。 #### サンプルをデプロイしてみる 1. 以下のリポジトリを clone してみます。`# git clone https://github.com/googleCloudPlatform/kubernetes-engine-samples` 2. guest book をデプロイしてみます。`# cd kubernetes-engine-samples/guestbook/ # kubectl apply -f . deployment.apps/frontend created service/frontend created deployment.apps/redis-follower created service/redis-follower created deployment.apps/redis-leader created service/redis-leader created` 3. 以下のコマンドでデプロイされる様子をみてみましょう。数分かかります。 `watch -n 1 kubectl get po` こんな感じになれば成功です。 Plain textcontent\_copy ``` NAME READY STATUS RESTARTS AGE frontend-c6b6bcf97-7gsw4 1/1 Running 0 2m15s frontend-c6b6bcf97-8f5gt 1/1 Running 0 2m16s frontend-c6b6bcf97-d6s9m 1/1 Running 0 2m15s redis-follower-9844c595f-gk7dd 1/1 Running 0 2m13s redis-follower-9844c595f-hrld4 1/1 Running 0 2m14s redis-leader-7b4fc9f49c-w69tj 1/1 Running 0 2m14s ``` おそらく、しばらく最初の方は Pending ステータスの Pod がいくつかあったと思います。 もしや・・・？ 早速 node 情報を取得してみます。 Plain textcontent\_copy ``` # kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-shimziu-autopilot-1-default-pool-8cae60ca-201z Ready 17m v1.18.12-gke.1210 gk3-shimziu-autopilot-1-default-pool-8cae60ca-91j8 Ready 2m24s v1.18.12-gke.1210 gk3-shimziu-autopilot-1-default-pool-8cae60ca-tbx9 Ready 2m14s v1.18.12-gke.1210 gk3-shimziu-autopilot-1-default-pool-f5dfb22d-1tv5 Ready 2m25s v1.18.12-gke.1210 gk3-shimziu-autopilot-1-default-pool-f5dfb22d-9qtb Ready 17m v1.18.12-gke.1210 ``` やはり、 node の数が増えていますね。 そうです、Autopilot モードは Node を必要な分だけ自動でスケールしてくれるのです。 [ドキュメント](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview?_ga=2.266046665.-794142402.1598253757#comparison)から、スケーリングに関する部分だけ抜粋してみました。 | Options | Autopilot mode | Standard mode | | --- | --- | --- | | Nodes and node pools | Managed by GKE. | Managed, configured, and specified by you. | | Provisioning resources | GKE dynamically provisions resources based on your Pod specification. | You manually provision additional resources and set overall cluster size. Configure cluster autoscaling and node auto-provisioning to help automate the process. | | Scaling | Pre-configured: Autopilot handles all the scaling and configuring of your nodes. Default: You configure Horizontal pod autoscaling (HPA) You configure Vertical Pod autoscaling (VPA) | Optional: Node auto-provisioning You configure cluster autoscaling. HPA VPA | | Billing | Pay per Pod resource requests (CPU, memory, and ephemeral storage) | Pay per node (CPU, memory, boot disk) | 上記でやはり気になるのは課金方法についてでしょう。 従来は、自身でプロビジョニングした Node ごとに料金が加算されていましたが、 Autopilot は pod にリクエストされた CPU、Memory、Storage リソースに対してのみ料金が計算されます。 最後に、pod の数を変更してみましょう deployments の名前を確認して Plain textcontent\_copy ``` # kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE frontend 3/3 3 3 4h40m redis-follower 2/2 2 2 4h40m redis-leader 1/1 1 1 4h40m ``` 直接リソースを変更し、保存します Plain textcontent\_copy ``` # kubectl edit deploy/frontend spec: progressDeadlineSeconds: 600 replicas: 6 # 3 -> 6 に変更 ``` しばらく待って、ちゃんとデプロイされていれば問題ないでしょう。 Plain textcontent\_copy ``` NAME READY STATUS RESTARTS AGE frontend-c6b6bcf97-7gsw4 1/1 Running 0 4h46m frontend-c6b6bcf97-8f5gt 1/1 Running 0 4h46m frontend-c6b6bcf97-d6s9m 1/1 Running 0 4h46m frontend-c6b6bcf97-knkbr 1/1 Running 0 3m8s frontend-c6b6bcf97-sc98m 1/1 Running 0 3m8s frontend-c6b6bcf97-skmnk 1/1 Running 0 3m7s redis-follower-9844c595f-gk7dd 1/1 Running 0 4h46m redis-follower-9844c595f-hrld4 1/1 Running 0 4h46m redis-leader-7b4fc9f49c-w69tj 1/1 Running 0 4h46m ``` リソースを削除し、クラスタを削除して今日はここまで。 Plain textcontent\_copy ``` # kubectl delete -f . ``` * * * #### Autopilot が標準モードと違うところ [GCPUG](https://www.youtube.com/watch?v=8Q3JRMSklGg) を見て改めて確認してみました。 ※ 一部抜粋 - Node へ SSH できない (ただ kubectl get nodes などリソース情報は見れる) - GKE Pod に対して 99.9% の SLO (2つ以上のzoneにPodが配置されること。偏りを避けたい場合、topologySpredConstraints を使用するとよい) - Podのスケジューリングに対してスケールするため、スパイクを備えて Node を事前にプロビジョニングすることができない - CPU と Memory の比率が 1:1 〜 1:6.5 (n1-standardなら1:0.9~) - sysctl / kubelet のチューニングができない 便利さの裏には、多少なりともトレードオフがあるようです。 ### 感想 ここまでで、従来のマニフェストを使用しながら(DaemonSet や Pod Affinity も使えます)も、良い塩梅で k8s の管理を GKE Autopilot が代わりに行ってくれることがわかりました。 Node という概念を Autopilot がマネージしてくれ、僕たちが考慮すべきところが減った点はかなり嬉しいですね。よく、「リクエストされたリソースが不足しています」とGKEに怒られた思い出があるので、その辺の管理から開放されるのはとてもありがたいです。 ドキュメント曰く、 HPA や VPA でスケールすることが可能なようなので、負荷をかけながら試してみたいところです。 昨今のネット記事では、プロビジョニングされる Node を意識しなくて良い、という点で AWS の ECS Fargate と比較されるようですが、 k8s の知識を生かすのであれば GKE Autopilot を使う方がいいと思いました。 パッと思いつくケースとして、 AWS には親しみはあるけど、k8sは・・・という人は ECS Fargate を、 k8s に親しみがあり、マニフェストベースで開発したい・・・という人は GKE Autopilot を使用、 sysctl/kubeletのチューニングが必要な場合や大規模なリソースをホストするなど、よりリソースのパフォーマンスを追求しなければならない場合などは従来のスタンダードを使えば良いのかな と感じました。 また、ここまでの個人的な印象としては従来の多くのケースが Autopilot でカバーできそうな気がしますし(もちろん、これからガッツリ触って標準モードで運用すべき場合を考えないといけませんが)、初期の開発段階では `とりあえず Autopilot で構築` して、実現できないケースがあれば `GKE 標準モードのクラスタに移す` といった流れでも十分だと思います。 逆に、そこまで複雑なことをすること自体が正しいのかを立ち止まって振り返り、アーキテクチャを見直すのも良いと思います。 これから使うケースはどんどん増えそうな気がしますね。 ではでは、また会いましょう。 #### 参照 \[Introducing GKE Autopilot\] [https://www.youtube.com/watch?v=\_JKsv2BtAnY](https://www.youtube.com/watch?v=_JKsv2BtAnY) \[Official Doc: Autopilot overview\] [https://g.co/gkeautopilot](https://g.co/gkeautopilot) \[GCPUG Tokyo GKE Day March 2021\] [https://www.youtube.com/watch?v=8Q3JRMSklGg](https://www.youtube.com/watch?v=8Q3JRMSklGg) ## この記事を書いた人 [![](/_astro/shimichan.B6KTYu8c_Z1NDayG.webp)](/authors/shimichan/) ### [shimichan](/authors/shimichan/) shimichanのプロフィールと執筆記事をご覧いただけます。 [プロフィールと記事一覧](/authors/shimichan/)