昨日（2021/02/25）に、GKE AutopilotがGAになりました 🎉

今までは、GKEを使う場合Podが動くNodeは自分で管理する必要がありましたが、GKE Autopilotを使うとNodeもGCPが管理してくれるようになり、運用負荷が大きく減少します。AWSのEKS for Fargateに近いサービスといったイメージでしょうか。Google Cloudの方が書いた日本語の記事がとても分かりやすいので、詳しくは以下をご覧ください。

Elastic Cloud on Kubernetes (ECK)は動かせるのか？

公式ドキュメントやブログを漁っていたのですが、CRD (Custom Resource Definition)やOperatorに関する記述は見当たりませんでした（探し方が悪いだけかもしれませんが…）。そこで、私が普段運用していてCRDやOperatorが使われているECKを実際に動かしてみました。

環境の差異を考慮するのが面倒なので、今回はすべての操作を管理コンソールだけで完結させます。

GKE Autopilotのクラスタを作る

GKEの管理コンソールからクラスタを作成しようとすると、以下のようなダイアログが表示されます。今回はAutopilotのクラスタを作成したいので、下の「構成」ボタンを押します。

クラスタの設定を入力する画面が表示されるので、好きな名前とリージョンを入力し、他はデフォルトのまま作成します。

しばらく待つと、Autopilotのクラスタが作成されます。

クラスタを操作するためにCloud Shellを起動する

クラスタ詳細画面の「接続」を押すとダイアログが出るので、「CLOUD SHELL で実行」を押してCloud Shellを起動します。起動するとクレデンシャルを取得するコマンドが入力されているので、そのままEnterキーを押してkubectlコマンドを使える状態にします。

$ gcloud container clusters get-credentials autopilot-sample-cluster --region asia-northeast1 --project YOUR_PROJECT_ID

実行結果

Fetching cluster endpoint and auth data.
kubeconfig entry generated for autopilot-sample-cluster.

クラスタにECKをデプロイする

Quickstartの手順どおりにコマンドを実行するだけです。

$ kubectl apply -f https://download.elastic.co/downloads/eck/1.4.0/all-in-one.yaml

実行結果

namespace/elastic-system created
serviceaccount/elastic-operator created
secret/elastic-webhook-server-cert created
configmap/elastic-operator created
customresourcedefinition.apiextensions.k8s.io/agents.agent.k8s.elastic.co created
customresourcedefinition.apiextensions.k8s.io/apmservers.apm.k8s.elastic.co created
customresourcedefinition.apiextensions.k8s.io/beats.beat.k8s.elastic.co created
customresourcedefinition.apiextensions.k8s.io/elasticsearches.elasticsearch.k8s.elastic.co created
customresourcedefinition.apiextensions.k8s.io/enterprisesearches.enterprisesearch.k8s.elastic.co created
customresourcedefinition.apiextensions.k8s.io/kibanas.kibana.k8s.elastic.co created
clusterrole.rbac.authorization.k8s.io/elastic-operator created
clusterrole.rbac.authorization.k8s.io/elastic-operator-view created
clusterrole.rbac.authorization.k8s.io/elastic-operator-edit created
clusterrolebinding.rbac.authorization.k8s.io/elastic-operator created
service/elastic-webhook-server created
statefulset.apps/elastic-operator created
validatingwebhookconfiguration.admissionregistration.k8s.io/elastic-webhook.k8s.elastic.co created

いろいろと作成されますが、動いているPodはOperatorだけです。

Elasticsearchをデプロイし、疎通確認する

こちらもQuickstartの手順どおりにコマンドを実行するだけです。

$ cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.11.1
  nodeSets:
  - name: default
    count: 1
    config:
      node.store.allow_mmap: false
EOF

実行結果

elasticsearch.elasticsearch.k8s.elastic.co/quickstart created

実行結果はすぐに返ってきますが、Elasticsearchの起動にはそこそこ時間がかかります。気長に待ちましょう。

ちなみに、起動に時間がかかる理由は、リソースの状態やイベントを追いかけた限り以下の3点です。

Elasticsearchを起動するためのリソースが既存のNodeに足りておらず、新しいNodeが起動される
Elasticsearch自体の起動にかかる時間が長い
Elasticsearchが起動してからReadiness probeが通るまでにかかる時間が長い

正常に起動したら、以下のような状態になります。kubectlコマンドでも確認できます。

$ kubectl get es

実行結果

NAME         HEALTH   NODES   VERSION   PHASE   AGE
quickstart   green    1       7.11.1    Ready   9m28s

それでは、疎通確認します。この手順もQuickstartにあるとおりです。

$ kubectl port-forward service/quickstart-es-http 9200 &
$ PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o go-template='{{.data.elastic | base64decode}}')
$ curl -u "elastic:$PASSWORD" -k "https://localhost:9200"

実行結果

Handling connection for 9200
{
  "name" : "quickstart-es-default-0",
  "cluster_name" : "quickstart",
  "cluster_uuid" : "67nczScjQ86NyyzgmIqLJg",
  "version" : {
    "number" : "7.11.1",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "ff17057114c2199c9c1bbecc727003a907c0db7a",
    "build_date" : "2021-02-15T13:44:09.394032Z",
    "build_snapshot" : false,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

ということで、GKE AutopilotでもECKが使えることが確認できました ✨

最後に

k8sでNodeを自分で管理するのはそれなりに大変ですし、動いているPodが少なくNodeのリソースをフル活用できていなくてもNodeを使っている分の料金を払わなければいけません。その点、GKE AutopilotはPodごとの課金なので、よりアプリケーションの開発・運用に集中できて良いですね。k8sに慣れている方であれば、Cloud Run等の他のマネージドサービスよりも有力な選択肢になるのではないでしょうか。もちろん向き不向きもあるので、そこは各自で判断してください。