grasys blog

Nodeの管理が楽になるGKE Autopilotを試してみた

文●shimichan/grasys 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

本記事はgrasys が提供する「grasys blog」に掲載されたGKE Autopilotを試してみたを再編集したものです。

 boom boom! Hello Cloud!

 どうも、しみちゃんでございます。

 今日は、今話題のGKE Autopilotを試してみたのでチュートリアルと使用感のご紹介をしたいと思います。

 GKE Autopilotが2021年2月25日にリリースされました。

記事: Introducing GKE Autopilot: a revolution in managed Kubernetes

GKE Autopilot とは?

 GKEの新たな操作・管理モードです。

 今までのGKEの管理モード(標準モード)クラスタ・コントロールプレーンの管理に加え、Nodeの管理を良い感じにGoogle Cloudが代わりに行ってくれると言うものです。

 「GKEってなんやねん」って方は、まずはこちらの公式を見ましょう。

とりあえずやってみよう、ということで試してみました。

実際に作ってみる

 まずはクラスターを作りましょう。

1. Webコンソールからナビゲーションメニュー → Kubernetes Engineのページへ移り、[作成]ボタンを押します。

2. 標準モードかAutopilotモードかを選択します。もちろんここではAutopilotを選択します.

3. クラスタ名とリージョンを指定し、デフォルトで[作成]ボタンを押します

4. しばらく待って、こんな感じでクラスターが作成されればOK

動かしてみる

 とても簡単にクラスターは作れたのではないでしょうか?

 次は、実際に操作してみましょう!

まずは接続から

 まずはクラスタのクレデンシャルを取得します。

 作成したクラスタの一番右のボタンから[接続]を押します。

2. するとgcloudコマンドが出てくるので、コピーします


3. コピーしたコマンドをターミナルから発行します。

# 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があるのか見てみます

# 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年3月時点)では 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

 こんな感じになれば成功です。

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情報を取得してみます。

# 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を必要な分だけ自動でスケールしてくれるのです。

 ドキュメントから、スケーリングに関する部分だけ抜粋してみました。
 

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の名前を確認して

# 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


 直接リソースを変更し、保存します

# kubectl edit deploy/frontend
spec:
  progressDeadlineSeconds: 600
  replicas: 6 # 3 -> 6 に変更


 しばらく待って、ちゃんとデプロイされていれば問題ないでしょう。

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

 リソースを削除し、クラスタを削除して今日はここまで。

# kubectl delete -f .

Autopilot が標準モードと違うところ

 GCPUGを見て改めて確認してみました。

※ 一部抜粋

・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

[Official Doc: Autopilot overview]
https://g.co/gkeautopilot

[GCPUG Tokyo GKE Day March 2021]
https://www.youtube.com/watch?v=8Q3JRMSklGg

■関連サイト

過去記事アーカイブ

2021年
03月
04月
05月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月