GKE

あけましておめでとうございます。本年はアウトプットの数を増やすという目標のもと、さっそくブログの更新をする。 年末年始は友人・家族と会えたし、飲みすぎないようにしたおかげで溜まってた本の解消やBLEACH全巻読んだりと充実できた。 去年、学んだk8sのGateway APIについて記事を書く。 Gateway APIとは Gateway APIは動的なインフラストラクチャの展開と高度なトラフィックルーティングを提供するAPIの種類のファミリーです。 とのこと。これだけだとわかりにくいが、要はk8sへの通信を担うLBをコード化して自動管理しようっていう認識であっていると思う。詳しくは、以下リンクでk8sやGCPの公式ドキュメントをみると理解が深まると思う。特に、GCPのドキュメントは具体的にどのリソースと紐づくのがわかりやすいので、GCPを知っている人はこっちを読むのをおすすめする。 https://kubernetes.io/ja/docs/concepts/services-networking/gateway/ https://docs.cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ja きっかけ 学んだきっかけは、会社でGKE StandardからAutopilot移行をしたときに、Autopilotクラスタが利用可能なすべてのゾーンにNEGが作成されていない状態で、手動でLBを作成すると障害になるケースがある。 という事象を発見したから。移行時の話は以下リンクから見れるので興味ある方は見てほしい。 所属している会社のアドベントカレンダーを書いた2025 さわってみた Gateway APIはk8sのマニフェストファイルを増やすことで実装できる。 kustomizeを利用する前提でディレクトリ構成を以下に記載する。GCPの場合は、LB作成時に必要なフロント、バック、ヘルスチェック、バックに登録するNEGをそれぞれ表現しているイメージを持ってもらうのがわかりやすそう。 また、GKEのPodでNginxを立てている想定でサンプルは実装している。 k8s/ └── base/ ├── configmap.yaml ├── deployment.yaml ├── gateway.yaml ├── healthcheck.yaml ├── httproute.yaml ├── kustomization.yaml └── service.yaml Gateway APIに関係している実装は、gateway.yaml, healthcheck.yaml, httproute.yaml, service.yamlなので、それぞれサンプル実装を記載して解説をする。 gateway.yaml kind: Gateway では利用するLBの種類やトラフィックをリッスンする場所と方法などの設定ができる。 addressesは予約したIPを指定して利用することもできる。 apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: nginx namespace: default spec: gatewayClassName: gke-l7-rilb # Regional Internal Load Balancer listeners: - name: http port: 80 protocol: HTTP allowedRoutes: namespaces: from: All addresses: - type: NamedAddress value: nginx healthcheck.yaml これはLB作成時に必要なヘルスチェック。 ...

久しぶりの投稿です。 ここ数年は広い領域の仕事をしていて、結構インプットができました。 アウトプットが少ないなと毎回思うので、ちょっとしたことでもいいのでブログ更新しようと思います。 継続って難しい。。 アドベントカレンダー書いた ということでQiitaのアドベントカレンダーを書いたのでURL載せておきます。 GKE StandardからAutopilotへの移行 Google CloudのGKE関連やネットワークには知見を貯めれました。こういったところの学びやハマりポイントなど記事にできるとよさそうかなと思っています。 あとは気分的に本ブログのドメインをサブドメでblog.yuyagishita.comにしたいかなと思っています。

久しぶりに記事書きました。 最近はObsidianに情報をまとめることが多いですが、もう少し気軽にアウトプットしようと思って書きました。 なので、詳細を調査はできていません。適当なこと書いてたらすみません。 発生した問題 タイトルにもある通りGKE Autopilotに関する話です。 AutopilotやPodバースト、水平Pod自動スケーリング（HPA）を知らない方はこれらの記事が参考になると思います。 Autopilot の概要 GKE で Pod バースト機能を構成する 水平Pod自動スケーリング 発生した問題についてですが、AutopilotクラスタでHPAを有効にしたDeploymentを上げたところ、Podが何度も再起動されながらHPAの最大値までPodが増えるといった挙動をしました。最大値までPodが増えたあとは再起動を何回もして不安定な状態でした。 原因 おそらく、Deploymentのresources.requestsが動かしているアプリに対して低すぎたことがこの状態を発生させていたと思います。 こんな感じの設定にしてました。 resources: requests: cpu: "50m" memory: "52Mi" limits: cpu: "500m" memory: "1Gi" コスト削減のため、リクエストを最も小さい値にしてました。 対象アプリがrequestsの値を大きく上回ってました。 Podバーストを有効にしているとlimitsはあくまで予約しているだけで実際にはリソースを確保していないということらしいので、以下のような解釈をしました。 requestsの値を大きく上回る HPAが適用される（HPAはCPUが80%で動くようにしてました。） Podが増える よくわからん挙動する 対処方法 requestsの値を対象アプリが要求している値の120%ぐらいにしました。 正常に動作するようになりました。 まとめ Autopilotクラスタを利用することで、Nodeの管理が必要なく運用が楽にはなりますが、自動で管理してくれる分よくわからないことも発生するので、手放しには喜べないなと思いました。 誰かの役に立ちそうなことがあれば、定期的に自分のメモを書いてるぐらいの感覚でブログを更新したいという気持ちです。