K8s

あけましておめでとうございます。本年はアウトプットの数を増やすという目標のもと、さっそくブログの更新をする。 年末年始は友人・家族と会えたし、飲みすぎないようにしたおかげで溜まってた本の解消や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の管理が必要なく運用が楽にはなりますが、自動で管理してくれる分よくわからないことも発生するので、手放しには喜べないなと思いました。 誰かの役に立ちそうなことがあれば、定期的に自分のメモを書いてるぐらいの感覚でブログを更新したいという気持ちです。

去年からちょっとずつ読んでた「Kubernetes完全ガイド 第２版」を読み終わりました。 なかなかボリュームのある本で668ページもあって読むのが大変でした。k8sを雰囲気しかしらない僕にとってはかなり勉強になる本で、体系的に学ぶことができk8sの全体像が頭に入ってきて解像度がかなり上がりました。 本のアウトプットも兼ねて感想とか気になったこととか書きます。 環境構築 この本はハンズオン形式なので、k8sの環境を作る必要があります。 僕は最初GKEを作成したのですが、費用がすぐに発生していやだったのでローカルで構築できるkindを利用しました。kindはDocker上でk8sを構築することができとても楽でした。ただ、他のブログなどをみてるとMinikubeがおすすめみたいです。kindはちょっとクセが強く一部の機能を動かすために設定が必要だったりしてたしかに初心者向けではないなと思いました。 図が多くて分かりやすい 大体のページに図があって、初めて知った概念などの理解をする補助になりました。文章読んでよくわからなかったら図を先にみて理解してました。 第７章までやれば基礎力が身につく この章まで終われば、一旦は基礎知識OKな気がしました。 仕事でk8sをさわらないけど、何をしているの知りたいとか動いてるGKEを追えるようになりたいとかの理由でこの本を読み始めた人は一旦区切りかなとか思います。 第９章　リソース管理とオートスケーリング k8sを利用する上でかなりのメリットかなと思いました。アプリの負荷にあわせてスケールアウトを自動でやってくれたりするのは可用性を高めてくれてかなりよきですね。 仕事で利用しているGKEではあまり高負荷がかかる場面もないのでここらへんの機能が効果的に発揮されてる場面に遭遇したことがほぼないのが残念です。 運用上のベストプラクティスをもっと知りたい この本を読んでて思ったのが、実際の運用だとどの機能をどれぐらい利用して構築しているんだろう、です。 ヘルスチェックや柔軟なスケジューリングやセキュリティなど便利な機能がたくさんあり、それらを知れてとてもよかったです。ただ、僕ぐらいのk8s初心者だと運用レベルをどれぐらい高めればいいのかって疑問がでてきました。何かしらのベンチマークとか取れたりするのかな。。今後そこらへんも調べたいと思いました。 この本は体系的にk8sを学べて最高です。文句とかは一切ないです。 マイクロサービスとの相性の良さ 複数のコンテナを安全に管理することができるk8sはやっぱりマイクロサービスとの相性はかなりいいですね。 逆にマイクロサービスでなく高負荷がかかったりしないモノリスなアプリだった場合はk8sはオーバースペックかもなと思いました。普通にCloud RunとかECSとかそういうので運用のほうが費用面も考えてコスパがいい気がしてます。もちろん、利用する言語や求められるシステムによっては選択はかなり変わると思いますが。 マイクロサービスやモノリスといった話はそのまま組織論として置換できそうで、大規模なアプリや多数の開発メンバーを抱えている組織だとそれぞれを分離させて管理できるk8sといった技術はかなり有用だなと改めて思いました。 逆に小さい組織の場合はもっとミニマムかつ小回りが聞く技術構成にしたりすると救われそうですね。 まとめ k8sの勉強において最高最強の本でした。 あと、GitOptsについてもこの本きっかけで理解が深まったのでよかったです。