GKE Autopilot を試す
kubectl のセットアップ
kubectl は Kubernetes のコマンドラインツールで、Kubernetes クラスターに対してコマンドを実行することができる
brew install kubectl
kubectl version --output=json
コンソール上から GKE クラスターの接続をクリックし、表示されたコマンドを実行
これにより kubectl と対象の GKE クラスターを紐付けることができた
kubectl から GKE クラスターの情報が取れるか確認
kubectl cluster-info
簡単なアプリケーションを動かす
簡単なヘルスチェック的なアプリケーションを動かす
LB を立てて、外部からアクセスできるようにする
参考
Deployment のマニフェストファイルは以下
apiVersion: apps/v1
kind: Deployment
metadata:
name: health-deployment
spec:
replicas: 1
selector:
matchLabels:
app: health
template:
metadata:
labels:
app: health
spec:
containers:
- name: health
image: asia-northeast1-docker.pkg.dev/[GCPプロジェクトID]/[リポジトリ名]/health:latest
今回は Artifact Registry に push したイメージを使っている
このイメージにビルドされているのは、/health
を実行したら、healthy
とレスポンスするだけのアプリケーション
また、コンテナーポートは 8080
Pod を起動する
上記のマニフェストファイルのreplicas
で Pod の数を調整できる
今回は 1 個にしているが、通常は冗長性を考慮し、複数個にする
kubectl apply -f deployment.yml
Node と Pod が起動していることを確認
kubectl get nodes
kubectl get pods
次は LB を作成する
LB の Service のマニフェストファイルは以下
apiVersion: v1
kind: Service
metadata:
name: health-service
spec:
type: LoadBalancer
selector:
app: health
ports:
- protocol: TCP
port: 9090
targetPort: 8080
selector.app
の値は Deployment の方の値と一致させる
kubectl apply -f service.yml
以下のコマンドを実行し、LB の ingress の IP をコピー
kubectl get service health-service --output yaml
curl [ingressのIP]:9090/health
healthy
が返ってくればオッケー
作成したリソースは削除しておく
kubectl delete -f deployment.yml
kubectl delete -f service.yml
もしくは、管理画面から GKE クラスターごと削除してもよい
(クラスターもそれなりに課金されるので)
GKE Autopilot について
GKE について
GKE はクラスターの統合エンドポイントであるコントロールプレーンと Node と呼ばれる複数の Worker で構成される
上記画像は以下から引用
- コントロールプレーン
- クラスターへの操作はすべてコントロールプレーンを経由し、コントロールプレーンは Kubernetes API サーバーへのリクエストを処理する
- Kubernetes API の呼び出しは、HTTP/gRPC 経由で直接呼び出すか、kubectl、コンソールからの UI 操作によって行う
- コントロールプレーンは、クラスター内のすべての Node で実行される処理を管理する
- コントロールプレーンと Node は、Kubernetes API を介して通信を行う
- クラスターへの操作はすべてコントロールプレーンを経由し、コントロールプレーンは Kubernetes API サーバーへのリクエストを処理する
- Node
- Node はクラスター作成時に GKE が自動で生成する
- 1 つ以上のコンテナーで構成される Pod は Node 上で動作する
従来の GKE Standard との違い
- Autopilot
- コントロールプレーンのフルマネージド
- アップデートも自動
- Node のフルマネージド
- アップデートも自動
- Pod 単位の課金と SLA
- クラスターの費用も別途かかる
- コントロールプレーンのフルマネージド
- Standard
- コントロールプレーンのフルマネージド
- アップデートも自動
- Node の管理は手動
- Node 単位の課金と SLA
- クラスターの費用も別途かかる
- コントロールプレーンのフルマネージド
LoadBalancer と Ingress について
GKE では、LoadBalancer と Ingress の 2 つのオプションがあります
両方ともトラフィックを GKE クラスター内のサービスへルーティングするために使用されますが、異なる仕組みで動作します
LoadBalancer
LoadBalancer は、L4(Transport Layer)負荷分散を提供し、トラフィックはクラスター内の Pod に分散されます
LoadBalancer を作成すると、外部 IP アドレスが割り当てられます
外部 IP アドレスを使用して、クラスター内のサービスにアクセスできます
LoadBalancer は、L4 負荷分散のみを提供するため、HTTP/HTTPS トラフィックを分散する場合は、Ingress を使用することが推奨されます
Ingress
Ingress は、L7(Application Layer)負荷分散を提供し、クラスター内のサービスに対する HTTP/HTTPS トラフィックを分散します
Ingress を使用すると、1 つの外部 IP アドレスで複数のサービスをルーティングでき、複数のサービスを同じドメイン名、ポート、またはパスで公開できます