Closed4

GKE Autopilot を試す

kurosamekurosame

kubectl のセットアップ

kubectl は Kubernetes のコマンドラインツールで、Kubernetes クラスターに対してコマンドを実行することができる

brew install kubectl
kubectl version --output=json

コンソール上から GKE クラスターの接続をクリックし、表示されたコマンドを実行

これにより kubectl と対象の GKE クラスターを紐付けることができた

kubectl から GKE クラスターの情報が取れるか確認

kubectl cluster-info
kurosamekurosame

簡単なアプリケーションを動かす

簡単なヘルスチェック的なアプリケーションを動かす
LB を立てて、外部からアクセスできるようにする

参考
https://cloud.google.com/kubernetes-engine/docs/how-to/exposing-apps?hl=ja#creating_a_service_of_type_loadbalancer

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 クラスターごと削除してもよい
(クラスターもそれなりに課金されるので)

kurosamekurosame

GKE Autopilot について

GKE について

GKE はクラスターの統合エンドポイントであるコントロールプレーンと Node と呼ばれる複数の Worker で構成される

上記画像は以下から引用
https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture

  • コントロールプレーン
    • クラスターへの操作はすべてコントロールプレーンを経由し、コントロールプレーンは Kubernetes API サーバーへのリクエストを処理する
      • Kubernetes API の呼び出しは、HTTP/gRPC 経由で直接呼び出すか、kubectl、コンソールからの UI 操作によって行う
    • コントロールプレーンは、クラスター内のすべての Node で実行される処理を管理する
      • コントロールプレーンと Node は、Kubernetes API を介して通信を行う
  • Node
    • Node はクラスター作成時に GKE が自動で生成する
    • 1 つ以上のコンテナーで構成される Pod は Node 上で動作する

従来の GKE Standard との違い

  • Autopilot
    • コントロールプレーンのフルマネージド
      • アップデートも自動
    • Node のフルマネージド
      • アップデートも自動
    • Pod 単位の課金と SLA
      • クラスターの費用も別途かかる
  • Standard
    • コントロールプレーンのフルマネージド
      • アップデートも自動
    • Node の管理は手動
    • Node 単位の課金と SLA
      • クラスターの費用も別途かかる
kurosamekurosame

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 アドレスで複数のサービスをルーティングでき、複数のサービスを同じドメイン名、ポート、またはパスで公開できます

このスクラップは2022/11/08にクローズされました