はじめに
こんにちは、いりすです。最近、バーチャル肉体を手に入れたけど直後にPCが壊れて悲しい思いをしました。
さて、最近、GKEのAutopilot modeがリリースされました。
https://cloud.google.com/blog/ja/products/containers-kubernetes/introducing-gke-autopilot
https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview?hl=ja
従来のnodeのスペックを自分で設定するものと異なり、nodeをgoogleにフルマネージドされたものとなっております。
それまでnode側を意識しなければならなかったGKEの運用がpodのみを考えれば良くなり、エンジニアがアプリケーション開発に注力できるような機能だと感じております。
特に、GCPUG Tokyo GKE Day March 2021にて、Autopilot modeが従来のモードとどう違うか、実装の詳細などが解説されており、非常にオススメです。
https://gcpug-tokyo.connpass.com/event/205839/
今回の記事では、GKE Autopilot modeでクラスタを立ててサンプルアプリケーションを構築して、機能お試しをします。
流れ
みんな大好きGKEのチュートリアルをautopilot modeでやるよ。
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app?hl=ja
- autopilot modeでclusterを作るよ
- GCRにイメージをpushするよ
- GKEにデプロイするよ
- デプロイしたclusterがどんな感じか見るよ
GKE Autopilotを試すよ
Clusterを作るよ
GCPコンソールのGKEサービス画面にて、クラスタ作成ボタンを押下、標準 or Autopilot かを聞かれるので、Autopilotの構成をクリックします。
クラスタ作成時の設定画面が出てきます。standardで存在したノードの設定などがなくなりシンプルになりました。
※ standardとの比較
今回はお試しなので、そのまま作成を押下します。
GCPへのRESTリクエストはこんな感じで、autopilot.enable=true が追加されてます。
POST https://container.googleapis.com/v1beta1/projects/[PROJECT_ID]/locations/us-central1/clusters
{
"cluster": {
"name": "[cluster name]",
"masterAuth": {
"clientCertificateConfig": {}
},
"network": "projects/[PROJECT_ID]/global/networks/default",
"addonsConfig": {
"httpLoadBalancing": {},
"horizontalPodAutoscaling": {},
"kubernetesDashboard": {
"disabled": true
}
},
"subnetwork": "projects/[PROJECT_ID]/regions/us-central1/subnetworks/default",
"networkPolicy": {},
"ipAllocationPolicy": {
"useIpAliases": true,
"clusterIpv4CidrBlock": "/17",
"servicesIpv4CidrBlock": "/22"
},
"masterAuthorizedNetworksConfig": {},
"networkConfig": {
"enableIntraNodeVisibility": true
},
"privateClusterConfig": {},
"verticalPodAutoscaling": {
"enabled": true
},
"shieldedNodes": {
"enabled": true
},
"releaseChannel": {
"channel": "REGULAR"
},
"clusterTelemetry": {
"type": "ENABLED"
},
"notificationConfig": {
"pubsub": {}
},
"initialClusterVersion": "1.18.12-gke.1210",
"location": "us-central1",
"autopilot": {
"enabled": true
}
}
}
※ gcloudコマンドで作成する場合は以下のようになってます。
gcloud container clusters create-auto [cluster name]
できた！
GCRにpush
tutorialの手順に従う
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app?hl=ja
- 事前準備:
gcloud services enable containerregistry.googleapis.com
gcloud auth configure-docker
- pushする
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/hello-app
export PROJECT_ID=project-id
docker build -t gcr.io/${PROJECT_ID}/hello-app:v1 .
docker push gcr.io/${PROJECT_ID}/hello-app:v1
clusterにデプロイ
consoleで作成したため、ローカルのkubeconfigに登録されてないので、GKE上から取得します。
gcloud container clusters get-credentials autopilot-cluster-1
kubectl config get-contexts # 確認
deploymentの作成
kubectl create deployment autopilot-cluster-1 --image=gcr.io/${PROJECT_ID}/hello-app:v1
最初こんな感じでUnschedulableで失敗しますが
ちょっと待つとOKになります 
podのwebappの動作確認(kubectl exec, kubectl port-forward)
チュートリアルではこの後browseしますが、そのままだと面白くないので、kubectl execしてrequestを飛ばしてみたり、port forwardingしてアプリを見てみます。
kubectlしてrequestしてみる:
$ wget -O - localhost:8080
Connecting to localhost:8080 ([::1]:8080)
writing to stdout
Hello, world!
Version: 1.0.0
port forwardingしてみる:
$ kubectl port-forward pod/autopilot-pod-1-759dc8b678-nzcr6 8080:8080
$ curl localhost:8080
Hello, world!
Version: 1.0.0
Hostname: autopilot-pod-1-759dc8b678-nzcr6
うむ。
デプロイしたclusterがどんな感じか見るよ
まず、GCEを見てみます。
$ gcloud compute instances list
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS
instance-2 asia-northeast1-b e2-micro 10.0.0.2 RUNNING
standard modeではnodeがGCEに紐づいてましたが、autopilot modeではユーザーの見られない場所に置かれてるようです。（過去に作ったインスタンスしかなかった）
次にnodeを見てみましょう。
$ kubectl get node
NAME STATUS ROLES AGE VERSION
gk3-autopilot-cluster-1-default-pool-59f96323-2tgn Ready <none> 3h23m v1.18.12-gke.1210
gk3-autopilot-cluster-1-default-pool-d800e826-0082 Ready <none> 17m v1.18.12-gke.1210
gk3-autopilot-cluster-1-default-pool-d800e826-v0z4 Ready <none> 3h23m v1.18.12-gke.1210
比較的新しく作成されたnodeを見てましょう
kubectl describe gk3-autopilot-cluster-1-default-pool-d800e826-0082
labelや、どのくらいリソースが使われてるかといったシステムの情報が見えます。
Labels: addon.gke.io/node-local-dns-ds-ready=true
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=e2-medium
beta.kubernetes.io/os=linux
cloud.google.com/gke-boot-disk=pd-standard
cloud.google.com/gke-netd-ready=true
cloud.google.com/gke-nodepool=default-pool
cloud.google.com/gke-os-distribution=cos
cloud.google.com/machine-family=e2
failure-domain.beta.kubernetes.io/region=us-central1
failure-domain.beta.kubernetes.io/zone=us-central1-a
iam.gke.io/gke-metadata-server-enabled=true
kubernetes.io/arch=amd64
kubernetes.io/hostname=gk3-autopilot-cluster-1-default-pool-d800e826-0082
kubernetes.io/os=linux
node.kubernetes.io/instance-type=e2-medium
topology.gke.io/zone=us-central1-a
topology.kubernetes.io/region=us-central1
topology.kubernetes.io/zone=us-central1-a
...
System Info:
Machine ID: 2fb79a32d388c3d0a9d98329351bbc38
System UUID: 2fb79a32-d388-c3d0-a9d9-8329351bbc38
Boot ID: 2926e9e0-eeb2-4a52-bf42-cdc97d5fbd15
Kernel Version: 5.4.49+
OS Image: Container-Optimized OS from Google
Operating System: linux
Architecture: amd64
Container Runtime Version: containerd://1.4.1
Kubelet Version: v1.18.12-gke.1210
Kube-Proxy Version: v1.18.12-gke.1210
PodCIDR: 10.8.0.128/26
PodCIDRs: 10.8.0.128/26
...
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 828m (88%) 600m (63%)
memory 2403Mi (85%) 2698Mi (95%)
ephemeral-storage 1Gi (2%) 1Gi (2%)
hugepages-2Mi 0 (0%) 0 (0%)
attachable-volumes-gce-pd 0 0
nodeのInstanceっぽい場所にping,sshしてみる。
Internal IPの情報があるので、同じネットワークにインスタンスを立ててアクセスしてみましょう。
Addresses:
InternalIP: 10.128.0.5
$ ping 10.128.0.5
PING 10.128.0.5 (10.128.0.5) 56(84) bytes of data.
64 bytes from 10.128.0.5: icmp_seq=1 ttl=64 time=2.09 ms
64 bytes from 10.128.0.5: icmp_seq=2 ttl=64 time=0.322 ms
64 bytes from 10.128.0.5: icmp_seq=3 ttl=64 time=0.351 ms
64 bytes from 10.128.0.5: icmp_seq=4 ttl=64 time=0.376 ms
64 bytes from 10.128.0.5: icmp_seq=5 ttl=64 time=0.561 ms
64 bytes from 10.128.0.5: icmp_seq=6 ttl=64 time=0.379 ms
64 bytes from 10.128.0.5: icmp_seq=7 ttl=64 time=0.395 ms
64 bytes from 10.128.0.5: icmp_seq=8 ttl=64 time=0.271 ms
64 bytes from 10.128.0.5: icmp_seq=9 ttl=64 time=0.412 ms
^C
--- 10.128.0.5 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 181ms
rtt min/avg/max/mdev = 0.271/0.572/2.086/0.540 ms
$ ssh 10.128.0.5
...
[user name]@10.128.0.5: Permission denied (publickey).
pingは通ったけど、さすがにsshはできなかったｗ
gcloud sshしてみる
じゃあ、gcloud sshはどうかを試してみます。
network内のすべてのリソースにTCP IAPをONにして、gcloud sshしてみましょう。
（なんかインスタンスを閲覧できない時点で無理な気がするけど）
- IAP用のfirewall設定を追加
普通のインスタンスへは接続できた。
$ gcloud compute ssh instance-3
...
irisu@instance-3:~$
nodeにはどうかな？
そもそもインスタンス名とzoneがわからないので、describeにあるかを調べてみます。
ProviderID: gce://[PROJECT_ID]/us-central1-a/gk3-autopilot-cluster-1-default-pool-d800e826-0082
こいつっぽいです。
zoneはus-central1-aで、instance名はgk3-autopilot-cluster-1-default-pool-d800e826-0082なので、gcloud sshで入ってみましょう。
$ gcloud config set compute/zone us-central1-a
$ gcloud compute ssh gk3-autopilot-cluster-1-default-pool-d800e826-0082
ERROR: (gcloud.compute.ssh) Could not fetch resource:
- The resource 'projects/[PROJECT_ID]/zones/us-central1-a/instances/gk3-autopilot-cluster-1-default-pool-d800e826-0082' was not found
ですよねー
なんか使ってて詰まったところとか
そういえば、nodeの権限ってどうなってるの
サービスアカウントを厳しくする（primitive roleはsecurityに引っかかるので、間違って権限を変えたり）と、image pullで失敗した過去があったので、今回も実験してみます。
Default compute service accountのサービスアカウントをCompute Adminにして、再度deployしてみます。
docker imageを新しくして、deployすることでGCRからpullできなくてpodが作成できなくなるはずです。
docker tag gcr.io/${PROJECT_ID}/hello-app:v1 gcr.io/${PROJECT_ID}/hello-app:v2
docker push gcr.io/${PROJECT_ID}/hello-app:v2
kubectl create deployment autopilot-pod-2 --image=gcr.io/${PROJECT_ID
}/hello-app:v2
nodeを管理しているGCEはDefault compute service accountを使ってるので無闇にいじると変なところで詰まります。
(ここら辺って公式に出てるのかな、だれか知ってたら教えてください 
)
おわりに
以上になります。
GKEのautopilot modeをお試しするためにチュートリアルをやってみたり、nodelessのnodeを見たり、nodeに乗り込もうとしてdenyされたりしました。
GKE autopilotを使うことで今まで管理していたnodeの管理を考えることなく利用でき、cloud runのように、よりアプリケーションに注力できそうな感じです。
実際に製品としての利用事例としてはPLAID様の事例が非常に参考になります。
ただ、nodeがmanagedになったので、今までできたnodeのsysctlとかはできなくなったので、大規模なアプリへの適用などは工夫が必要に思えます。
個人的には内部アプリやお遊びで作るアプリを立てたりする場にカジュアルに使えそうでぜひ導入していきたいです。
あと、terraformで管理したいマンなので、terraform対応が待ち遠しいです。
おしまい。
じゃあねー