2022-11-29

とにかく手軽に Kubernetes + Istio 環境を用意したい人のための GKE & ASM 入門

Kubernetes と Istio の組み合わせは、その拡張性やエコシステムの充実度などから、マイクロサービスの実行環境を検討する際の有力な選択肢のひとつに挙げられます。
一方、Kubernetes や Istio を構築・運用することが技術的なハードルとなり、アプリケーションの検証にまでなかなか到達できない、というケースもあるのではないでしょうか。
そこで今回は、「とにかく手軽に Kubernetes + Istio の環境が欲しい」といった方向けに、いま現在の Google Cloud で採りうる最もマネージドな構成をご紹介します。

概要

今回ご紹介する構成は、Kubernetes のマネージドサービスである GKE (Google Kubernetes Engine)と、Istio のマネージドサービスである Anthos Service Mesh を、GKE Autopilot + Managed Anthos Service Mesh + Managed Data Plane という利用形態で組み合わせたものです。

それぞれの簡単な説明は以下のとおりです。

GKE Autopilot は、GKE Standard と同様のマネージドなコントロールプレーンに加えて、ノードの管理も Google に任せることができる GKE クラスタの利用形態です。
Managed Anthos Service Mesh（以下、Managed ASM）は、従来から提供されてきた In-place Control Plane よりもさらにマネージドな範囲を拡大し、Istiod の運用も Google に任せることができる Anthos Service Mesh の利用形態です。
Managed Data Plane は、Managed ASM の Data Plane（サイドカーとしてワークロードの Pod に挿入される Istio-proxy）の運用を Google に任せることができるオプション機能として提供されています。

これまで、Managed ASM は GKE Standard のみがサポートされてきたこと、Managed Data Plane が GA していなかったことから、上記の組み合わせはサポートされていませんでしたが、2022 年 9 月に発表された下記リリースによってこれが実現可能となりました。
加えて、9 月 8 日のリリースでは、マルチクラスタのグルーピングやポリシー管理に用いられる Fleet API を使って Managed ASM を構成することが可能になったとアナウンスされていました。
今後は Fleet API の使用が推奨となるようですので、今回は Fleet API を使って ASM をセットアップする流れをご紹介します。

Managed ASM による GKE Autopilot のサポートが GA に到達

cloud.google.com

Managed ASM のオプションである Managed Data Plane が GA に到達
Fleet API による ASM のセットアップが GA に到達

cloud.google.com

GKE Autopilot クラスタの作成

まずは GKE Autopilot のクラスタを作成します。
今回は、特にオプションを付与しないプレーンなクラスタを作成します。
クラスタ作成のリクエスト後、しばらくするとステータスが Running となり、クラスタが正常に起動したことがわかります。

$ gcloud container clusters create-auto autopilot-cluster
Note: The Pod address range limits the maximum size of the cluster. Please refer to https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr to learn how to optimize IP address allocation.
Creating cluster autopilot-cluster in us-central1... Cluster is being health-checked (master is healthy)...done.     
Created [https://container.googleapis.com/v1/projects/***************/zones/us-central1/clusters/autopilot-cluster].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1/autopilot-cluster?project=***************
kubeconfig entry generated for autopilot-cluster.
NAME: autopilot-cluster
LOCATION: us-central1
MASTER_VERSION: 1.23.12-gke.100
MASTER_IP: ***************
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.23.12-gke.100
NUM_NODES: 3
STATUS: RUNNING

クラスタはコンソールで作成することもできます。
コンソールの場合は GKE Autopilot クラスタを作成する際にチェックボックスを入れることで Managed ASM を有効化できるようになっていますが、今回は Fleet API を使った手順をみていきましょう。

Fleet API による ASM のセットアップ

Fleet API を用いて Managed ASM を構成する手順は、下記の公式ドキュメントに記載されています。
ASM 1.11 以降、ここ 1 年ほどは、asm_install の後継である asmcli が推奨のインストール手段とされてきましたが、Managed ASM を利用する場合であれば今後は Fleet API による構成が推奨となるようです。

cloud.google.com

なお、Managed ASM を利用する場合であっても、以下の条件では引き続き asmcli を使って構成する必要があるため注意が必要です。

Managed ASM を VPC Service Controls で保護する必要がある場合
Istio-proxy が利用するｍTLS の証明書管理に（Mesh CA ではなく）プライベート CA を利用する場合
GKE のリリースチャネルと ASM のリリースチャネルが異なる場合

それでは、前節で作成した GKE Autopilot クラスタに Managed ASM をセットアップしていきましょう。
なお、説明の簡単のため、クラスタの作成とフリートの管理は同じプロジェクトで行うものとします。
また、これまでに一度も mesh.googleapis.com を有効化したことがない、フリート機能を使ったことがない、という場合は以下の手順を参考に事前作業が必要です。

cloud.google.com

作業前の状態では、クラスタは存在するものの、フリートには登録されていません。

$ gcloud container fleet memberships list
（出力なし）

クラスタをフリートに登録していきます。
Fleet API は、GKE URI という一意の識別子によって登録する GKE を特定するため、gcloud container clusters list に --uri オプションを付与して URI を取得しておきましょう。
メンバーシップ名は任意のようですが、クラスタ名と揃えておくと管理しやすいかと思います。

$ gcloud container clusters list --uri
https://container.googleapis.com/v1/projects/***************/locations/us-central1/clusters/autopilot-cluster

$ gcloud container fleet memberships register autopilot-cluster \
  --gke-uri=https://container.googleapis.com/v1/projects/***************/locations/us-central1/clusters/autopilot-cluster \
  --enable-workload-identity
  
Waiting for membership to be created...done.     
Finished registering to the Fleet.

$ gcloud container fleet memberships list
NAME: autopilot-cluster
EXTERNAL_ID: ***************
LOCATION: global

次に、mesh_id ラベルをクラスタに付与します。
これは ASM ダッシュボードにメトリクスを表示するなどの目的で利用されます。

$ gcloud container clusters update autopilot-cluster --update-labels mesh_id=proj-***************
Note: GKE Dataplane V2 has been certified to run up to 500 nodes per cluster, including node autoscaling and surge upgrades. You may request a cluster size of up to 1000 nodes by filing a support ticket with GCP. For more information, please see https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2
Updating autopilot-cluster...done.
Updated [https://container.googleapis.com/v1/projects/***************/zones/us-central1/clusters/autopilot-cluster].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1/autopilot-cluster?project=***************

余談ですが、GKE Autopilot では eBPF を使った CNI 実装のひとつである Cilium を使った Dataplane V2 が採用されているため、 Dataplane V2 を使用する場合のノード数上限に関する通知が出ていますね。

これで Managed ASM を設定する準備が整いました。
現状は、クラスタがフリートに登録されたものの、Managed ASM やそのオプションである Managed Data Plane は有効化されていない状態です。

$ gcloud container fleet mesh describe
createTime: '2021-10-11T05:47:33.463228309Z'
membershipSpecs:
membershipStates:
  projects/***************/locations/global/memberships/autopilot-cluster:
    servicemesh:
      controlPlaneManagement:
        state: DISABLED
      dataPlaneManagement:
        details:
        - code: DISABLED
          details: Data Plane Management is not enabled.
        state: DISABLED
    state:
      code: OK
      description: Please see https://cloud.google.com/service-mesh/docs/install for
        instructions to onboard to Anthos Service Mesh.
      updateTime: '2022-11-26T05:09:24.043654068Z'
name: projects/***************/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
state:
  state: {}
updateTime: '2022-11-26T05:11:32.289019496Z'

以下のコマンドで、Fleet API から Managed ASM を有効化することができます。

$ gcloud container fleet mesh update \
     --management automatic \
     --memberships autopilot-cluster

しばらく待ってから gcloud container fleet mesh describe コマンドで確認してみると、controlPlaneManagement, dataPlaneManagement がともにアクティブになっていることがわかります。

$ gcloud container fleet mesh describe
createTime: '2021-10-11T05:47:33.463228309Z'
membershipSpecs:
  projects/***************/locations/global/memberships/autopilot-cluster:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/***************/locations/global/memberships/autopilot-cluster:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
      updateTime: '2022-11-26T12:34:08.393270443Z'
name: projects/***************/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
state:
  state: {}
updateTime: '2022-11-26T12:35:12.350418568Z'

asmcli で有効化する場合と比較して、Fleet API を用いて Managed ASM を有効化する場合は Managed Data Plane もセットで有効化される点が特徴ですね。

ワークロードの実行とサイドカー（Data Plane）の挿入

環境が用意できましたので、ワークロードを実行する Namespace にラベルを付与して適当なワークロードをデプロイし、Istio-proxy が自動挿入されることを確認してみましょう。
今回は httpd を利用します。

$ kubectl describe namespace default
Name:         default
Labels:       kubernetes.io/metadata.name=default
Annotations:  <none>
Status:       Active

Resource Quotas
  Name:                              gke-resource-quotas
  Resource                           Used  Hard
  --------                           ---   ---
  count/ingresses.extensions         0     100
  count/ingresses.networking.k8s.io  0     100
  count/jobs.batch                   0     5k
  pods                               0     1500
  services                           1     500

No LimitRange resource.

$ kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite
label "istio.io/rev" not found.
namespace/default labeled

$ kubectl describe namespace default 
Name:         default
Labels:       istio-injection=enabled
              kubernetes.io/metadata.name=default
Annotations:  <none>
Status:       Active

Resource Quotas
  Name:                              gke-resource-quotas
  Resource                           Used  Hard
  --------                           ---   ---
  count/ingresses.extensions         0     100
  count/ingresses.networking.k8s.io  0     100
  count/jobs.batch                   0     5k
  pods                               1     1500
  services                           1     500

No LimitRange resource.

$ kubectl run httpd --image httpd
Warning: Autopilot set default resource requests on Pod default/httpd for container httpd, as resource requests were not specified, and adjusted resource requests to meet requirements. See http://g.co/gke/autopilot-defaults and http://g.co/gke/autopilot-resources.
pod/httpd created

$ kubectl get pod -o jsonpath='{.items[0].spec.containers[*].name}' |  tr ' ' '\n'
httpd
istio-proxy

補足：Control Plane と Data Plane をセットで有効化するための Google 側の工夫

上記の構成を試す過程で、Fleet API によって Managed ASM と Managed Control Plane をセットで有効化するために Google 側が実装面でどのような工夫をしているのか、ユーザが観測できる情報から少し覗いてみたいと思います。

Fleet API で ASM を有効化している最中に、gcloud container fleet mesh describe コマンドでステートを確認してみると、controlPlaneManagement のステートは以下のような順序で変化していました（過程のすべてのステートを拾えているかはわかりません）。

DISABLED → PROVISIONING (REVISION_PROVISIONING) → ACTIVE (REVISION_READY)

更に、dataPlaneManagement のステートは以下のように変化していました。

DISABLED → FAILED_PRECONDITION (MANAGED_CONTROL_PLANE_REQUIRED) → (Control Plane が ACTIVE に到達) → PROVISIONING (PROVISIONING) → ACTIVE (OK)

Fleet API は Managed Data Plane もセットで有効化するため、Control Plane より先に Data Plane が展開されてしまうことがないよう、Control Plane の展開が済むまでは FAILED_PRECONDITION で展開が止まるようになっているようですね。
Kubernetes のリコンサイルの仕組みを使って、Control Plane が条件を満たせば（Managed ASM がACTIVE になれば）、自動的に目的の状態（ACTIVE）に収束するよう定義し、展開の順序を制御しているようです。

まとめ

GKE Autopilot + Managed Anthos Service Mesh + Managed Data Plane の構成で GKE, ASM を利用することで、手軽に Kubernetes + Istio の環境を構築できることをご紹介しました。
次回は、この環境における ASM のバージョンコントロールの仕組みについてカスタムリソースなどから調べた情報を交えて共有したいと思います。

2022-10-24

Google Cloud Champion Innovator になりました

テクノロジー

このたび、Google Cloud の Champion Innovator (Modern Architecture, Security and Networking) になりました。
Security and Networking の分野では、日本から選出された初めての Champion になることができました。

Google Cloud Innovators

Google Cloud のグローバルな取り組みとして Google Cloud Innovators というプログラムが 2022 年から始まっています。
所属や組織に関係なく、Google Cloud に関わる開発者・技術者が互いに情報を共有し合うためのコミュニティ（メンバーシッププログラム）です。
日本では 2022 年 4 月に初めてのイベントが開かれたほか、今後はメンバ限定のロードマップセッションや、メンバ間の交流イベントなどが開かれていくようです（参考）。

グローバルなプログラムとして、Next などの年次カンファレンス内でのイベントだけでなく、世界各国でローカライズされたイベントも開かれています。
日本でも、これまでに Innovators Hive Japan や、 Innovators Live Japan など複数回イベントが開催されています。
私も Innovators Hive Japan では Google Cloud Partner Top Engineer Meetup #1 に参加しているほか、先日の Google Cloud Next ’22 にあわせて開催となった Innovators Hive at Google Cloud Next の東京開催では Ask the Expert のセッションに参加しています。

https://cloud.google.com/innovators

Google Cloud Champion Innovators

Champion Innovators は、Innovators プログラムにおける技術的なエキスパートとしてコミュニティをリードしてゆくような役割を持っていると理解しています。
Google Cloud の公式ページから引用させて頂くと、以下のようになっています。

一人ひとりが技術面でトップレベルであり、カンファレンス、オープンソースプロジェクト、フォーラム、ブログ、ワークショップ、コミュニティイベント、ソーシャルメディアに貢献することで、技術的な知識を共有し、Google Cloud コミュニティと Google のプロダクトチームに刺激を与え、活性化させ、挑戦するエキスパート

https://cloud.google.com/innovators/champions

Google 社員からの推薦で選出されるというプロセスなどから、GDE (Google Developer Experts) に近い位置付けではないかと思っています（あくまで私の想像です）。

私の場合は、Google 社員の方から Champion Innovators に興味はないかと推薦を持ちかけて頂き、認定にチャレンジしました。
選考プロセスの詳細は割愛しますが、エントリーに必要な活動実績を整理したり、Google 社員の方々との面接などを経て選出された、という感じです。

専門分野

Champion Innovators には、Cloud AI/ML, Database, Google Workspace などいくつかの専門分野が設定されています。
今回私は以下の2つの専門分野で Champion に認定して頂きました。

Modern Atchitecture
Security and Networking

むすび

Google Cloud Champion Innovator (Modern Architecture, Security and Networking) になりました。
Google Cloud のグローバルなコミュニティに関わる機会を頂いてとても嬉しく思うとともに、今後の活動を楽しみにしています。
コミュニティの活性化に貢献できるよう努めていきます。

2022-10-21

Google Cloud Certified Professional Cloud Database Engineer を取得しました

テクノロジー

Google Cloud が提供している認定資格、Professional Cloud Database Engineer を取得しました。
資格を取ったのは少し前なのですが、忘れないうちに受験準備や参照したリソースについて書き残しておきたいと思います。

試験概要

Professional Cloud Database Engineer は Google Cloud が認定するプロフェッショナル資格のひとつです。
Google Cloud のデータベース系サービスやソリューションに関する知識を問われる内容となっています。

https://cloud.google.com/certification/cloud-database-engineer

試験時間：2 時間
出題形式：多肢選択式
受験料：$200
試験官との応対言語：英語
試験問題の言語：英語

試験官との応対は英語で行います。
現状は、試験問題も英語のみの提供となっています。

受験方法

今回はオンラインで受験しました。
オンラインの場合は Webassessor の試験配信システムを利用するため、受験に用いる端末に Sentinel というクライアントをインストールしておく必要があります。
その他、受験に関する注意事項はひととおり目を通しておくことをおすすめします。

https://support.google.com/cloud-certification/answer/9907852?hl=ja&ref_topic=9433463

受験するときのテーブル上には、許可されたもの（ディスプレイ、キーボード、マウスetc.）以外は一切置くことができません。
ただし、私が受験した際はキーボードとマウスにそれぞれアームレストを使うことは許可されていました。

受験時の所感

Cloud SQL や Cloud Spanner などの Google Cloud のデータベースサービスの仕様や設計に関する知識を問う問題はもちろんのこと、IAM の管理や、オンプレミスからの移行計画など、運用に関する問題もかなり出題されている印象でした。
以下の URL に Google Cloud のデータベースのサービスの概要と主なユースケースが一覧化されていますので、ユースケースに応じて選択すべきサービスやソリューションがパッと思い浮かべられるようにしておくと良いかと思います。

https://cloud.google.com/products/databases

おわりに

Professional Cloud Database Engineer を取得しました。
受験準備を通じて、Google Cloud のデータベース関連の知識を再整理することができました。

また、この資格の取得をもって現在提供されている Google Cloud のプロフェッショナル資格をすべて取得し終えました。
次はどのようなカテゴリの試験が追加されるのか楽しみですね。

2022-09-21

GKE Standard に登場した高スループット版の Logging エージェントはこれまでと何が違うのか

テクノロジー

従来、GKE Standard の Logging エージェントは、ワークロードの出力ログ量に関わらず基本的には同じ設定の Logging エージェント (Fluent Bit) がデプロイされるようになっていました。
今回のアップデートでは、高いログスループットが求められる（1 秒あたりのログの処理量がより多い）ノードのために専用の Logging エージェントをデプロイする機能が追加されました。
Logging エージェントの何がどう変わったのか、実際にクラスタを用意して確認してみました。

今回のアップデートは下記のリリースノートから確認できます。
cloud.google.com

また、図らずも前回と少し関連した内容となったため、ノードあたりのPod数上限の拡張や、それに伴うコントロールプレーンの設定の違いなどにご興味がありましたらこちらも併せてご参照ください。

ユースケース

アップデートに併せて既に公式ドキュメントにも記載がありますが、ノードあたりのログスループットが 100 KB/s 超となるようなノードのために用意されたようです。

ノードプール毎の指定となるため、クラスタ内すべてのノードで高スループット版の Logging エージェントを使うこともできますし、特定のノードプールのノードに限って高スループット版を利用する、といった使い方もできるようになっています。
具体的な差異は後ほどご紹介しますが、高スループット版ではより多くの CPU, メモリを消費します。
そのため、ノードプール毎にログの出力量の異なるワークロードが稼働している場合には、特に高いログスループットが求められるノードプールを指定して利用する、というケースが多いのではないかと思います。

なお、新規クラスタはもちろんのこと、既存クラスタからのアップデートでもデプロイ可能ですが、利用するには GKE Standard のコントロールプレーンが 1.24.2-gke.300 以降である必要があります。
現状 GKE Autopilot では利用できません。

実機検証

それでは、実際にクラスタを構築して、通常の Logging エージェントと高スループット版の Logging エージェントの違いを見ていきたいと思います。

1. クラスタを作成する

今回のアップデートの対応バージョンは 1.24.2-gke.300+ となっていますが、今回は 1.24.2 の最新のパッチバージョンである 1.24.2-gke.1900 を使用して GKE Standard のクラスタを作成しました。

まずは通常の Logging エージェントを利用するためのノードプールを e2-medium で用意しました。
説明の簡単のため、ノード数は 1 としています。

作成したクラスタは以下のとおりです。（見やすさのためリソースの表示順序は入れ替えています）

$ gcloud container clusters describe sample-gke
name: sample-gke
...
currentMasterVersion: 1.24.2-gke.1900
currentNodeCount: 1
currentNodeVersion: 1.24.2-gke.1900
...
loggingConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
    - WORKLOADS
loggingService: logging.googleapis.com/kubernetes
...
nodePoolDefaults:
  nodeConfigDefaults:
    loggingConfig:
      variantConfig:
        variant: DEFAULT
nodePools:
- name: default-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    machineType: e2-medium
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...

2. 高スループット版 Logging エージェントをデプロイする

次に、クラスタに別のノードプールを追加し、高スループット版 Logging エージェントをデプロイすることで、ひとつのクラスタに通常の Logging エージェントと高スループット版の Logging エージェントが 1 ノードずつデプロイされている状態にしていきます。

以下のように、ノードプールの作成時に --logging-variant=MAX_THROUGHPUT オプションを指定することで、高スループット版の Logging エージェントをデプロイするノードプールを作成します。
インスタンスタイプは先ほどよりも大きな e2-standard-4 としました。

$ gcloud container node-pools create "additional-pool" --cluster "sample-gke" --logging-variant=MAX_THROUGHPUT
（他のオプションは割愛）
...
Note: Node version is specified while node auto-upgrade is enabled. Node-pools created at the specified version will be auto-upgraded whenever auto-upgrade preconditions are met.
Creating node pool additional-pool...done.     
Created [https://container.googleapis.com/v1beta1/projects/***********/zones/us-central1-a/clusters/sample-gke/nodePools/additional-pool].
NAME: additional-pool
MACHINE_TYPE: e2-standard-4
DISK_SIZE_GB: 100
NODE_VERSION: 1.24.2-gke.1900

$ gcloud container clusters describe sample-gke
name: sample-gke
...
currentMasterVersion: 1.24.2-gke.1900
currentNodeCount: 2
currentNodeVersion: 1.24.2-gke.1900
...
loggingConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
    - WORKLOADS
loggingService: logging.googleapis.com/kubernetes
...
nodePoolDefaults:
  nodeConfigDefaults:
    loggingConfig:
      variantConfig:
        variant: DEFAULT
nodePools:
- name: default-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    machineType: e2-medium
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...
- name: additional-pool
  initialNodeCount: 1
  config:
    ...
    imageType: COS_CONTAINERD
    loggingConfig:
      variantConfig:
        variant: MAX_THROUGHPUT
    machineType: e2-standard-4
    ...
  maxPodsConstraint:
    maxPodsPerNode: '110'
  ...

なお、GKE クラスタの作成やノードプールの追加は GUI コンソールからも作成が可能ですが、高スループット版の Logging エージェントをデプロイする場合、現状はコマンドラインからの API リクエストが必要です。

3. 通常の Logging エージェントと高スループット版の Logging エージェントを比較する

それでは、各ノードプールにデプロイされた通常の Logging エージェントと高スループット版の Logging エージェントの YAML を取得し、主な差異を比較していきたいと思います。

3.1. イメージの比較

まずは各エージェントのコンテナイメージを確認してみましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、YAML の差異を VS Code で比較したものです。

高スループット版の Logging エージェントでは、fluentbit-gke-max-... という名前になるようですね。
313 行目 (fluentbit-gke-max では 331 行目) で確認できるとおり、高スループット版 Logging エージェントでも、引き続き Fluent Bit が使われています。
イメージのパスも一致していることから、高スループット版 Logging エージェントは「従来の Logging エージェントと同様に Fluent Bit のイメージを使っており、設定の違い (チューニング) によって高スループットを実現している」ことがわかります。

3.2. Fluent Bit の設定の違い

Logging エージェントのイメージは同一であることがわかったため、次にコンテナ毎の設定の違いを見ていきましょう。
Daemonset でデプロイされる Logging エージェントの Pod には、以下の 3 つのコンテナが定義されています。

ノードからログを収集する Fluent Bit (fluentbit)
収集したログを Cloud Logging に転送する Exporter (fluent-bit-gke-exporter)
初期化処理を行う InitContainer (fluentbit-gke-init)

通常稼働時は Pod に Fluent Bit と Exporter の 2 つのコンテナが存在していることになります。
まずは Fluent Bit の設定の違いを見ていきましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、 YAML の Fluent Bit の定義付近を比較したものです。

Fluent Bit のコンテナ単位の Request / Limit (特に CPU Request) が大幅に引き上げられていることがわかります。
その他の定義には大きな差異はなく、設定ファイルも同じ ConfigMap を読み込んでいるため、Fluent Bit としては割り当てリソースの引き上げによって高スループット版を実現していると言えそうです。

3.3. Exporter の設定の違い

次に、Exporter の設定の違いを見ていきましょう。
以下の図は、左を通常版の Logging エージェント、右を高スループット版の Logging エージェントとして、 YAML の Exporter の定義付近を比較したものです。

Exporter の CPU Request もまた、大幅に引き上げられていることがわかります。
加えて、コマンドの引数には通常版の Logging エージェントにはなかった --pod-cache-size=512 というオプションが追加されています。
このオプションはノードあたりの Pod 数上限を 111 以上に拡張した場合にも付与されていることから、通常版の Logging エージェントよりもログスループットが要求される場合に設定されるオプションのようです。

その他の定義には大きな差異はなく、設定ファイルも同じ ConfigMap を読み込んでいました。

補足 (fluent-bit-gke-exporter の役割)

fluent-bit-gke-exporter に関しては Google Cloud がプライベートに管理しているイメージのため情報が少ないですが、設定ファイルなどからその役割を推測することができます。
Fluent Bit の設定ファイルである fluent-bit.conf を含む ConfigMap として fluentbit-gke-config-* が Namespace: kube-system にデプロイされており、その OUTPUT セクションの定義を見ると、2020 ポートで稼働している Fluent Bit から、収集したログを 2021 ポートで稼働している Exporter に渡していることがわかります。
設定値からの推測ではありますが、fluent-bit-gke-exporter は収集したログを Cloud Logging に転送する役割を持っていると考えられます。

[SERVICE]
    Flush         5
    Grace         120
    Log_Level     info
    Log_File      /var/log/fluentbit.log
    Daemon        off
    Parsers_File  parsers.conf
    HTTP_Server   On
    HTTP_Listen   0.0.0.0
    HTTP_PORT     2020

...

[OUTPUT]
    Name        http
    Match       *
    Host        127.0.0.1
    Port        2021
    URI         /logs
    header_tag  FLUENT-TAG
    Format      msgpack
    Retry_Limit 2

高スループット版利用時の注意

高スループット版の Logging エージェントを利用する際は、適用先のノードプールのインスタンスタイプに注意が必要です。
Fluent Bit と Exporter がそれぞれ Request で 1 CPU を要求しているため、少なくともスケジュール先のノードが 2 CPU 以上のリソースを持っていなければなりません。

したがって、例えば割当可能な CPU が少ない e2-medium や e2-standard-2 では高スループット版 Logging エージェントが利用できません。
インスタンスタイプが小さい場合は --logging-variant=MAX_THROUGHPUT のオプションを付与してしまうと Logging エージェントが Unschedulable (割り当て不可) の状態となってしまうため、通常の Logging エージェントを利用しましょう。

まとめ

新しく GKE Standard で選択可能となった高スループット版 Logging エージェントについて調べました。
内部の実装は従来どおり Fluent Bit を使っており、割り当てリソースの引き上げによって高スループット版を実現していることがわかりました。

2022-08-18

GKE Standard の Node あたりの Pod 数上限が 256 に増えた

テクノロジー

従来、GKE Standard における Node あたりの Pod 数上限は 110 でした。
2022 年 8 月にアップデートがあり、この上限が 256 に引き上げられたため、実際にクラスタを用意して確認してみました。

アップデートは下記のリリースノートから確認できます。

cloud.google.com

ユースケース

アップデート後も Node あたりの Pod 数上限のデフォルトは引き続き 110 となっていますが、ひとつの Node に対してより多くの Pod を収容可能にしたいというユースケースはいくつか考えられます。
例えば以下のようなケースが挙げられるでしょう。

Node 課金な SaaS / MW のコスト最適化
スケールアップ / アウトのバランス調整

なお、従来は /24 の Pod CIDR に対して 110 Pod が上限となっていたため、今回のアップデートによってネットワークアドレスの空きがより少ないクラスタ構成が可能になるのでは、という期待があるかもしれませんが、アドレスレンジは設定した Pod 数上限の倍以上が引き続き必要となります。
そのため、Node あたりの Pod 数上限を 129〜256 としたい場合は /23 を設定する必要があります。

実機検証

それでは、実際にクラスタを構築して Node あたりの Pod 数上限の引き上げが機能していることを確認したいと思います。

1. クラスタを作成する

今回のアップデートの対応バージョンは 1.23.5-gke.1300+ となっていますが、今回は最新の静的リリースである 1.24.3-gke.200 を使用して GKE Standard のクラスタを作成しました。
説明の簡単のため、ノードは 1台のみとしています。
また、Node あたりの Pod 数上限は 256 、Pod CIDR は /23 に設定しました。

作成したクラスタは以下のとおりです。

$ gcloud container clusters describe testcluster-1
...
currentMasterVersion: 1.24.3-gke.200
currentNodeCount: 1
currentNodeVersion: 1.24.3-gke.200
...
defaultMaxPodsConstraint:
  maxPodsPerNode: '110'
...
name: testcluster-1
...
nodePools:
- maxPodsConstraint:
    maxPodsPerNode: '256'
  name: default-pool
  networkConfig:
    podIpv4CidrBlock: 10.88.0.0/14
    podRange: gke-testcluster-1-pods-d26f61e4
  podIpv4CidrSize: 23
  ...

ちなみに、 Node あたりの Pod 数上限は Web コンソールの GKE クラスタ作成画面からも設定することができます。
対応していないバージョンで設定を行おうと試みたところ、図のようにエラーが表示され、この拡張がサポートされているバージョンであるかを確認できるようになっていました。

2. Pod を大量に作成する

クラスタが起動したので、1 台の Node に対して従来の上限である 110 を超える Pod を起動してみます。
下記の要領で、httpd の Pod を 245 作成しました。

$ for i in {1..245}; \
> do kubectl run httpd${i} --image=httpd; \
> done;
pod/httpd1 created
pod/httpd2 created
pod/httpd3 created
...
pod/httpd245 created

3. Pod の状態を確認する

Pod の作成が完了したので、各 Pod の STATUS を確認してみます。

$ kubectl get pods
NAME    READY   STATUS  RESTARTS     AGE
httpd1  1/1         Running 0            6m51s
httpd10 1/1         Running 0            6m18s
httpd100    1/1         Running 0                5m25s
httpd101    1/1         Running 0            5m24s
httpd102    1/1         Running 0            5m24s
httpd103    1/1         Running 0            5m23s
httpd104    1/1         Running 0            5m22s
httpd105    1/1         Running 0            5m22s
…

$ kubectl get pods | grep Running | wc -l
245

$ kubectl get pods | grep -v Running
NAME    READY   STATUS  RESTARTS     AGE

すべて起動しており、ひとつの Node に従来の上限 (110) を超える Pod を立ち上げられることが確認できました。

4. 更なる Pod の追加

更に Pod を追加してみます。
246 番目に追加した httpd の Pod はこれまでと違い、Pending になってしまいました。

$ kubectl run httpd246 --image=httpd
pod/httpd246 created

$ kubectl get pod httpd246
NAME    READY   STATUS  RESTARTS     AGE
httpd246    0/1         Pending 0            4m44s

5. kube-system の Pod を確認する

前項の httpd246 の Pod が起動できなかったのは、既にこの Node に上限いっぱいの 256 Pod が起動していたためです。
今回手動で追加した httpd の Pod は 245 まででしたが、kube-system Namespace を確認すると、Control Plane の一部としてシステム系の Pod が起動していることがわかります。
以下のように、1.24.3-gke.200 では 11 Pod が存在していました。

$ kubectl get pods -n kube-system | awk '{print $1}'
NAME
event-exporter-gke-...
fluentbit-gke-256pd-...
gke-metrics-agent-...
konnectivity-agent-...
konnectivity-agent-autoscaler-...
kube-dns-...
kube-dns-autoscaler-...
kube-proxy-gke-testcluster-1-pool-1-...
l7-default-backend-...
metrics-server-v0.5.2-...
pdcsi-node-...

$ kubectl get pods -A | grep Running | wc -l
256

Node あたりの Pod 数の上限は当然ながらシステム系の Pod を含むため、 httpd246 の Pod は起動できずスケジューリング待ちとなりました。

Control Plane の工夫

Fluent Bit の Request / Limit の引き上げ

今回のアップデートに対応するかたちで、Google Cloud が管理する Control Plane 側にもいくつかの変更が加えられています。
そのひとつが、先程の kube-system Namespace に起動している Fluent Bit です。

Fluent Bit は Pod のログを Cloud Logging に転送する役割を持っており、従来は fluentbit-gke-... という Pod 名で DaemonSet によって展開されていましたが、今回は Pod 名が fluentbit-gke-256pd-... となっています。
この違いは Node あたりの Pod 数の上限を引き上げたことに関係しているのではと考え、Pod 数の上限をデフォルトの 110 としたクラスタを別途作成し、Fluent Bit の Yaml を比較してみました。
主な差分は以下のとおりで、図の左側が Pod 数の上限をデフォルトの 110 としたクラスタ、右側が Pod 数の上限を 256 としたクラスタに展開されていた Fluent Bit の Yaml です。

fluentbit-gke-256pd-... では、Fluent Bit も Exporter もリソースの Request / Limit が引き上げられている事がわかります。これは、Node に出力されたコンテナのログを収集する Fluent Bit の消費リソースが、Node 上に起動する Pod 数に大きく影響を受けるためと考えられます。

補足

GKE は Fluent Bit を DaemonSet で展開して各 Node のコンテナのログを Cloud Logging に転送する、という方式でクラスタレベルのロギングを実現しています。
Kubernetes でクラスタレベルのロギングを行うためのアーキテクチャには 3 つの選択肢がありますので、気になる方は以下を参照ください。

kubernetes.io

Nodepool に応じた DaemonSet の展開

Node あたりの Pod 数の上限の拡張は Nodepool 毎に設定できるため、今後はひとつのクラスタに複数種類の Pod 数上限の Node が混在する可能性があります。
Fluent Bit は DaemonSet で展開されるため、fluentbit-gke の DaemonSet と fluentbit-gke-256pd の DaemonSet の使い分けが必要になります。
確認してみたところ、GKE は NodeAffinity によって Node 毎に展開する Fluent Bit を制御していることがわかりました。

以下の Yaml の差分がそれを表しています。

matchExpressions の設定を見るに、以下のような設計としているようです。

Pod 数上限が 8 ~ 110 の (あるいは明示的に上限をしていない) Node : 従来と同じ fluentbit-gke を展開
Pod 数上限が 111 ~ 256 の Node : リソースの Request / Limit を増やした fluentbit-gke-256pd を展開

まとめ

Node の Pod 数上限を 256 まで拡張できるようになったことを確認しました。
実機での確認を通じて、このアップデートに対応して Control Plane にも工夫がみられることがわかりました。

2022-07-29

Google Cloud Certified Professional Machine Learning Engineer を取得しました

テクノロジー

Google Cloud が提供している認定資格、Professional Machine Learning Engineer を取得しました。
受験準備や参照したリソースについて書き残しておきたいと思います。

試験概要

Professional Machine Learning Engineer は Google Cloud が認定するプロフェッショナル資格のひとつです。
Google Cloud の ML 系サービスやソリューションに関する知識を問われる内容となっています。

https://cloud.google.com/certification/machine-learning-engineer

試験時間：2 時間
出題形式：多肢選択式
受験料：$200
試験官との応対言語：英語
試験問題の言語：英語

試験官との応対は英語で行います。
現状は、試験問題の文面も英語のみの提供となっています。

受験方法

https://support.google.com/cloud-certification/answer/9907852?hl=ja&ref_topic=9433463

受験時の所感

Vertex AI や Auto ML などの Google Cloud のサービスに関する知識を問う問題はもちろんのこと、状況に応じた学習アルゴリズムの選択・モデルが適切なパフォーマンスを発揮できない場合の対処方法・モデルの品質評価方法など、ML の一般知識に関する問題もそれなりに出題されている印象でした。
テキスト・自然言語・画像など、Google Cloud には多種多様なソースを目的に応じて分類・分析できる様々な ML サービスがありますので、ユースケースに応じて選択すべきサービスやソリューションがパッと思い浮かべられるようにしておくと良いかと思います。

おわりに

Professional Cloud Machine Learning Engineer を取得しました。
受験準備を通じて、Google Cloud の ML 関連の知識を再整理することができました。

2022-06-21

Google Cloud Certified Professional Cloud Network Engineer を取得しました

テクノロジー

Google Cloud が提供している認定資格、Professional Cloud Network Engineer を取得しました。
受験準備や参照したリソースについて書き残しておきたいと思います。

試験概要

Professional Cloud Network Engineer は Google Cloud が認定するプロフェッショナル資格のひとつです。
Google Cloud の Network に関するプラクティス・設計に関する知識を問われる内容となっています。

https://cloud.google.com/certification/cloud-network-engineer

試験時間：2 時間
出題形式：多肢選択式
受験料：$200
試験官との応対言語：英語
試験問題の言語：英語

試験官との応対は英語で行います。
現状は、試験問題の文面も英語のみの提供となっています。

受験方法

https://support.google.com/cloud-certification/answer/9907852?hl=ja&ref_topic=9433463

受験時の所感

VPC 内のルーティングや負荷分散の問題はもちろんのこと、Cloud Interconnect や Cloud Router など、オンプレミスとのハイブリッド構成に関する問題もそれなりに出題されました。
Network Interigence Center など、ネットワーク関連の補助的なサービスも学習しておくとよいのではと思います。

おわりに

Professional Cloud Network Engineer を取得しました。
受験準備を通じて、Google Cloud のネットワーク関連の知識を再整理することができました。

概要

GKE Autopilot クラスタの作成

Fleet API による ASM のセットアップ

ワークロードの実行とサイドカー（Data Plane）の挿入

補足：Control Plane と Data Plane をセットで有効化するための Google 側の工夫

まとめ

Google Cloud Innovators

Google Cloud Champion Innovators

専門分野

むすび

試験概要

おすすめの学習リソース

試験ガイド

模擬試験

受験方法

受験時の所感

おわりに

実機検証

1. クラスタを作成する

2. 高スループット版 Logging エージェントをデプロイする

3. 通常の Logging エージェントと高スループット版の Logging エージェントを比較する

3.1. イメージの比較

3.2. Fluent Bit の設定の違い

3.3. Exporter の設定の違い

補足 (fluent-bit-gke-exporter の役割)

高スループット版利用時の注意

まとめ

実機検証

1. クラスタを作成する

2. Pod を大量に作成する

3. Pod の状態を確認する

4. 更なる Pod の追加

5. kube-system の Pod を確認する

Control Plane の工夫

Fluent Bit の Request / Limit の引き上げ

補足

Nodepool に応じた DaemonSet の展開

まとめ

試験概要

おすすめの学習リソース

Google Cloud の Medium ブログ

模擬試験

受験方法

受験時の所感

おわりに

試験概要

おすすめの学習リソース

Google Cloud の Medium ブログ

Google のネットワークを知る

受験方法

受験時の所感

おわりに