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



動かしてみる

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

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

まずは接続から

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

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

  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    <none>   7m45s   v1.18.12-gke.1210
    gk3-shimziu-autopilot-1-default-pool-f5dfb22d-9qtb   Ready    <none>   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
    

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

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    <none>   17m     v1.18.12-gke.1210
gk3-shimziu-autopilot-1-default-pool-8cae60ca-91j8   Ready    <none>   2m24s   v1.18.12-gke.1210
gk3-shimziu-autopilot-1-default-pool-8cae60ca-tbx9   Ready    <none>   2m14s   v1.18.12-gke.1210
gk3-shimziu-autopilot-1-default-pool-f5dfb22d-1tv5   Ready    <none>   2m25s   v1.18.12-gke.1210
gk3-shimziu-autopilot-1-default-pool-f5dfb22d-9qtb   Ready    <none>   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