※当サイトの記事には、広告・プロモーションが含まれます。

GKE(Google Kubernetes Engine)について調べてみた

www.itmedia.co.jp

gigazine.net

GPT-3.5やGPT-4などの大規模言語モデルは、インターネット上のさまざまなコンテンツを学習することで、ユーザーからの質問やプロンプトに応えています。OpenAIが2023年8月に技術ドキュメントなどを公開したウェブクローラーGPTBot」は、アクセスが許可されているウェブサイトから自動で情報を取得し、GPT-4や将来的に公開されるGPT-5などの大規模言語モデルの改善に役立てられるとされています。

OpenAIが将来のAIモデルの改善に向けたウェブクローラー「GPTBot」を発表、同時にAIによる無断での学習を防ぐためのブロック方法も公開 - GIGAZINE

⇧「Microsoft Bing」も内部的に「GPT-4」を利用してるはずだから、「Microsoft Bing」も影響を受けるってことかね?

Kubernetesとは?

GitHubで公開されてるKubernetesの公式の情報によると、

github.com

Kubernetes, also known as K8s, is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for the deployment, maintenance, and scaling of applications.

https://github.com/kubernetes/kubernetes

⇧ コンテナ化されたアプリケーションを管理するシステムですと。ちなみに、Googleの社内で活用されてた技術を一般公開したものらしく、Google発祥の技術でありますと。

コンテナってのは、

kubernetes.io

Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.

https://en.wikipedia.org/wiki/Docker_(software)

⇧ サーバーにおける仮想化の技術ってことかと。WikipediaのDocker(コンテナを世に広めた)の説明によると、OSレベルの仮想化になるらしい。

Kubernetesに話を戻すと、Kubernetesの全体構成としては、

⇧ 上図のようになるらしい。

公式の情報では無いけども、

github.com

⇧「Node」の部分を「Worker Node」と呼ぶこともあるっぽい。

と思ったら、

⇧ 公式でも「Worker Node」って言葉を使ってるドキュメントもあった...

う~む、用語の定義が曖昧やな...

話を戻すと、コンテナ化されたアプリケーションは、「Node」の中に「Pod」というKubernetesのオブジェクトが配置され、その中に含まれるようです。

「Node」の中身としては、

www.netone.co.jp

zenn.dev

⇧ 上図のような構成になるようです。「Pod」やコンテナの数はまちまちになると思いますが。通信が複雑やね...

GKE(Google Kubernetes Engine)とは?

公式のドキュメントの説明によると、

console.cloud.google.com

Google Kubernetes Engine is a powerful cluster manager and orchestration system for running your Docker containers. It's built on the open source Kubernetes system, giving you the flexibility to take advantage of on-premises, hybrid, or public cloud infrastructure.

https://console.cloud.google.com/marketplace/product/google-cloud-platform/container-engine

Google Cloud上で動作するKubernetes環境ということかと。

クラウドのベンダー依存してそうね。

cloud.google.com

⇧ 上図にあるように、「Control Plane」部分は「GKE(Google Kubernetes Engine)」が管理するとなっているので、標準の「Kubernetes」を利用する場合との違いに気を付ける必要がありそう。

「GKE(Google Kubernetes Engine)」には、

運用モード

GKE には、Autopilot と Standard の運用モードがあり、さまざまなレベルの柔軟性、責任、制御を提供します。フルマネージド Autopilot モードをおすすめします。このモードでは、Google Cloud がノードを管理し、ワークロードに重点を置いてコストを最適化し、本番環境に対応した環境を提供します。

https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview?hl=ja#modes_of_operation

⇧ 運用モードというものがあるらしく、

  1. Autopilot
  2. Standard

の2つが用意されているようで、「Autopilot」を選ぶと「ノード」部分についても「GKE(Google Kubernetes Engine)」で管理されることになるらしい。

で、

cloud.google.com

Autopilot の代わりに Standard を使用する場合

ほとんどのワークロードには Autopilot を使用することをおすすめしますが、事前構成済みの強化やデフォルトのクラスタ構成により、Autopilot が満たせない特定の要件がある場合があります。次のような場合は、Autopilot モードではなく Standard モードを使用することをおすすめします。

  • SSH を使用してノードに直接接続するなど、クラスタやノードの構成を細かく制御する必要がある場合。

https://cloud.google.com/kubernetes-engine/docs/concepts/choose-cluster-mode?hl=ja

⇧ とあるように、「Autopilot」モードだと、「ノード」に対してもSSH接続ができなくなるらしい。つまり、コンテナに対しても外部からSSH接続でもログインはできなくなるらしい。

まぁ、もう一つ気になるのは、何故に、

  1. Autopilot
  2. Standard

のモードの変更方法を記載しないのか、不思議でしょうがないのだが...

「Autopilot」モードだけど、「Standard」モードに変更が必要なユースケースのための説明であるなら、モードの変更方法について説明があって然るべきなのではないのか...

Googleに所属してるような頭の良い人が考えてることはよく分からん...

と思ったら、

cloud.google.com

GKE のクラスタでは、次のオペレーション モードが用意されています。

  • 自動パイロット モード(推奨): GKE は、ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ構成、ベースライン ネットワーキング構成など、基盤となるインフラストラクチャを管理します。
  • 標準モード: 個々のノードの構成など、基盤となるインフラストラクチャを管理します。

クラスタの作成後に、クラスタを Standard から Autopilot に変換することはできません。

https://cloud.google.com/kubernetes-engine/docs/concepts/kubernetes-engine-overview?hl=ja#modes_of_operation

⇧ らしい。

であるなら、「Autopilot の代わりに Standard を使用する場合」でクラスターを作り直す必要があるってことを記述しておいた方が親切な気がするんだが...

それにしても、後から変更できないって、サービスとしてどうなのよ...

変更できるようにしておけば良い気がするんだけど、不親切な仕様だわな...

とりあえず、「GKE(Google Kubernetes Engine)」においては、本番環境では「Autopilot」を推奨しているようです。

Google Cloud のサービスとやり取りする方法

公式の情報ではないのだけど、

medium.com

⇧ 全部で4つの方法に分類できる模様。

不思議でしょうがないのが、上図のようなまとめ情報がGoogle Cloudの公式のドキュメントで見当たらないという...

GKE(Google Kubernetes Engine)に対する疎通方法(管理)

「GKE(Google Kubernetes Engine)」で稼働しているアプリケーションへの疎通ではなくて、「GKE(Google Kubernetes Engine)」を管理するための疎通についての話。

アプリケーションのデプロイとか、障害が起きた時とかを想定。

Googleさんの推奨する方法は分からんのですが、

cloud.google.com

Cloud Shell には、Google Cloud CLI と kubectl コマンドライン ツールがプリインストールされています。gcloud CLIGoogle Cloud への主要なコマンドライン インターフェースを提供し、kubectl は Kubernetes クラスタにコマンドを実行するための主要なコマンドライン インターフェースを提供します。

https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster?hl=ja

⇧ ブラウザからアクセスする「Google Cloud コンソール」に付随してる「Cloud Shell」を利用するケースを紹介しており、

の2つを紹介している。

が、ドキュメントでは、デプロイに関しては、「kubectl」コマンドを利用するケースしか紹介されておらず、「gcloud CLI」が利用できるのかが不明。

いまいち、「gcloud CLI」と「kubectl」の使い分けがハッキリしない...

「Autopilot」モードで作成されたクラスターでは、SSH接続ができないのだけど、「kubectl」コマンドであれば、コンテナ(「Pod」を経由しての接続)へ接続することはできるらしい。

Google Cloud」を利用する案件で、「GKE(Google Kubernetes Engine)」を利用する機会が訪れたら、他にも詳しく調べる必要が出てくるとは思うけど、ザックリと概要だけは把握。

ソースコードだけじゃなくドキュメントも可読性って大事だよね...

最初に書いてあったでしょ、ってのは、10000行で1つの処理になっているようなソースコードにおけるグローバル変数みたいな感じで認知負荷が高くなるから好きでない(個人的見解)...

ちなみに、Kubernetes のドキュメントによると、

⇧ 基本的には、「Control Plane(Master Node)」の「API Server」経由で、その他のKubernetesのオブジェクトを操作する感じになるんかね?

毎度モヤモヤ感が半端ない...

今回はこのへんで。