More than 5 years have passed since last update.

GKE試行（その3：「クラスタ作成」）

Posted at 2018-09-15

お題

前回は作成した適当に作ったアプリをGitHubからCloud Source Repositoriesに連携し、Cloud Buildを使ってDockerイメージをビルドしてContainer Registryにプッシュするところまでやった。
今回は、いよいよGKE上で動かすところまで。いけるかな・・・？

環境

前回と同じ。

前提

自前でGCPプロジェクトは契約済み
gcloudをローカルで使える状態になっている

実践

１）GKEクラスタ作成　→　失敗

手順として、GKEで一番大きな「箱」である「クラスタ」を作る。
クラスタは概念・・・なのか？
以下に「Kubernetes Engine クラスタとは、Kubernetes を実行する Compute Engine インスタンスのグループです。」とあった。
https://cloud.google.com/kubernetes-engine/docs/clusters/?hl=ja
なるほど。
「クラスタ　＝　GCEインスタンスグループ」

ということは、クラスタを作ると、中にいくつかの「GCEインスタンス」を作ることになるんだろうな。
インスタンスグループについては以下に説明がある。
https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances?hl=ja
「マネージドインスタンスグループは自動スケーリング、負荷分散、ローリング更新などをサポート」

”自動スケーリング”するみたい。以下にも説明がある。
https://cloud.google.com/compute/docs/autoscaler/?hl=ja

**　１クラスタには複数のGCEインスタンスが含まれ、自動スケーリングする**

はい、とりあえずここまでの理解で、いったんクラスタ作ってしまおう。
クラウドコンソールとgcloudコマンドによる２通りの方法それぞれ試してみる。
https://cloud.google.com/kubernetes-engine/docs/clusters/operations?hl=ja

１−１）クラウドコンソールでGKEクラスタ作成

あれっ？　また、権限かな？
gcloudコマンドの方も試してみよう。
最低限のオプションでクラスタ作成を試みる。チュートリアルでは、クラスタ名とゾーンを渡しているので真似る。
いつも忘れてしまうゾーン。↓に一覧が載っている。
https://cloud.google.com/compute/docs/regions-zones/?hl=ja

以下のように、自分がローカルでgcloudコマンド使って初期設定した時にリージョンをどう設定したかは確認できる。


koge@koge-W65-67SF:~$ gcloud config list
[compute]
region = asia-northeast1
[core]
account = 【アカウントに使っているメアド】@gmail.com
disable_usage_reporting = False
project = 【プロジェクトID】

Your active configuration is: [default]

「asia-northeast1」は a 〜 c のどれかを付けた名前でゾーンが存在する。

さあ、gcloudコマンドでのクラスタ生成を試してみよう。


koge@koge-W65-67SF:~$ gcloud container clusters create go-webapi-for-gke-study-clusters --zone asia-northeast1-a
WARNING: Starting in 1.12, new clusters will have basic authentication disabled by default. Basic authentication can be enabled (or disabled) manually using the `--[no-]enable-basic-auth` flag.
WARNING: Starting in 1.12, new clusters will not have a client certificate issued. You can manually enable (or disable) the issuance of the client certificate using the `--[no-]issue-client-certificate` flag.
WARNING: Currently VPC-native is not the default mode during cluster creation. In the future, this will become the default mode and can be disabled using `--no-enable-ip-alias` flag. Use `--[no-]enable-ip-alias` flag to suppress this warning.
This will enable the autorepair feature for nodes. Please see
https://cloud.google.com/kubernetes-engine/docs/node-auto-repair for more
information on node autorepairs.

WARNING: Starting in Kubernetes v1.10, new clusters will no longer get compute-rw and storage-ro scopes added to what is specified in --scopes (though the latter will remain included in the default --scopes). To use these scopes, add them explicitly to --scopes. To use the new behavior, set container/new_scopes_behavior property (gcloud config set container/new_scopes_behavior true).
ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Google Compute Engine: Required 'compute.networks.get' permission for 'projects/【プロジェクトID】/global/networks/default'.

うん、「compute.networks.get」権限がないのでダメとのこと。
前回は、「サービスアカウント「○○」にビルド権限がない」というエラーだったので、指定されたサービスアカウントにIAMで権限を付与して解決した。
今回は、どのサービスアカウントがって指定されない。困った。

トラブルシューティング

ぐぐると、IAMポリシーを確認しろとあった。


koge@koge-W65-67SF:~$ gcloud projects get-iam-policy 【プロジェクトID】
bindings:
- members:
  - serviceAccount:806987825204@cloudbuild.gserviceaccount.com
  role: roles/cloudbuild.builds.builder
- members:
  - serviceAccount:projectowner@【プロジェクトID】.iam.gserviceaccount.com
  - user:【アカウントに使っているメアド】@gmail.com
  role: roles/owner

前回に続き再び登場の「806987825204」。
前回与えたロール「cloudbuild.builds.builder」のみだから、ここに「compute.networks.get」（そもそもこれはロール？）を追加すればいいんだろうか。

いったん「Compute管理者」を付けてみた。

リトライ


koge@koge-W65-67SF:~$ gcloud container clusters create go-webapi-for-gke-study-clusters --zone asia-northeast1-a
　　〜〜〜
ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Google Compute Engine: Required 'compute.networks.get' permission for 'projects/【プロジェクトID】/global/networks/default'.

ダメだった。試しにプロジェクトのオーナーロールを付与してみてもダメだった。
そういう問題ではないらしい・・・。

そして、ぐぐっては試しのトライ＆エラーを繰り返した後、あきらめて別プロジェクトを作ることにした。。。
業務でやってたら、あきらめるという選択肢はないけど、プライベートであまりにも本筋でないところでハマるとやる気なくなるので。

２）別プロジェクトにて再度GKEクラスタ作成

２−１）クラウドコンソールでGKEクラスタ作成

**　来たっ！**

あ〜、完全に前のGCPプロジェクトでいろいろいじり過ぎていたせいだ・・・。
よくよく考えるとネットワーク周りをいろいろ消したりもした気が・・・。
完全に無駄な数時間を・・・。

気を取り直して。
各項目を設定していく前にGKEのクラスタについて、おさらい。
「クラスタ　＝　GCEインスタンスグループ」
なので、クラスタの中には複数のGCEインスタンスが含まれる。
このGCEインスタンスのことをGKEでは「ノード」と呼ぶ。
クラスタ作成のメニューとは、そこに含むGCEインスタンスのスペックをどうするか、
GCEインスタンス（＝ノード）をいくつ起動するかを決めるものということか。

ちなみに、クラスタのアーキテクチャについては以下参照。
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture?hl=ja

では、クラスタ作成メニュー。項目別に。

【クラスタ名】

特に言及することは無し。

【ロケーションタイプ　〜　ノードプール　〜　可用性】

[ゾーン]

ここはロケーションタイプで「ゾーン」を選択するか「リージョン」を選択するかで変わるので一括して扱う。

デフォルトでは「ゾーン」。つまり、１ゾーンを指定し、その中で複数のノード（＝GCEインスタンス）を立ち上げる。
なので、ゾーン障害が起きたらアウト。

「ノードプール」で指定するノード数も単純にいくつノード（＝GCEインスタンス）を立ち上げておくかの指定となる。
ノードプールについては以下に説明がある。
https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools?hl=ja

さて、「ノードプールを追加」というのが気になる。
ノードプールでは複数の同じ構成のノードを用意するものらしい。
深みに嵌りそうなのでまだ考えない方がいい気がするけど、実際にアプリを乗せる場合、１つのWebアプリだけなら１つのノードプールで事足りるだろうけど、
マイクロサービスでシステム作ってたりすると複数のサービスをそれぞれコンテナイメージにしているから、
そうなると、１つのノードプールでは事足りず、サービス毎にノードプールを用意するという感じになるのか・・・？

単一のゾーンではゾーン障害に弱いので複数のゾーンを利用するように設定するもの。（ただ、当然、同じリージョン内に限る）
https://cloud.google.com/kubernetes-engine/docs/concepts/multi-zone-and-regional-clusters?hl=ja&_ga=2.6685618.-1642231062.1533503848

あと、ノードプール数、マルチゾーンにするかどうか、このあたりが立ち上がるGCEインスタンス数に直結するので、当然、かかるお金も変わってくる。

[リージョン]

「ゾーン」と異なり、最初から同一リージョンの複数ゾーンにノードを用意する前提なので、そのような設定の仕方になる。
可用性の部分はデフォルトではチェック無しになっていて、その場合は全ゾーンを対象とする。

マルチゾーンクラスタとリージョンクラスタの違い

どちらも同一リージョン内に限る点は同じだし、複数のゾーンにノードを配置できる点も同じ。
違いは、「クラスタマスター」の作成数。
クラスタマスターは、クラスタ内の全ノードと通信し、ノード内のアプリ（Dockerコンテナ）のスケジューリング、ライフサイクル管理、スケーリング、アップグレードを管理するコントローラー役。
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture?hl=ja#master
そのクラスタマスターを１ゾーンにだけ配置するのが「マルチゾーンクラスタ」で、ゾーンすべてに配置するのが「リージョンクラスタ」。
https://cloud.google.com/kubernetes-engine/docs/concepts/multi-zone-and-regional-clusters?hl=ja