Blog

2025 年 4 月 1 日から Docker Hub の Rate Limit が引き締められ、未認証ユーザによるイメージ Pull は 1 時間あたり 10 回まで に制限されました。Rate Limit に引っかかると、Docker Hub からのイメージ Pull が一定の期間規制されるため、コンテナが起動できなくなる危険があります。 特に、マネージド Kubernetes の場合、イメージ Pull はクラスタの IP（NAT IP 等）アドレスを送信元としてリクエストされるため、同一の IP アドレスから大量の Pull リクエストを送信すると、その IP に対して Docker Hub の Rate Limit が適用されます。このため、単一の Pod が Rate Limit に引っかかると、他の Pod もイメージの取得ができなくなり、ImagePullBackOff や ErrImagePull に陥る可能性があります。今回は Google Cloud Artifact Registry の Remote Repository と Amazon ECR の Pull Through Cache を活用した Docker Hub の Rate Limit 対策を紹介したいと思います。

2024 年 10 月から約 3 ヶ月に渡り Google Cloud が主催する Google Cloud Innovators Gym #9（通称 G.I.G.）というプログラムに参加してきたので、振り返りも兼ねてブログを書きたいと思います。 今後参加される方や、Google Cloud 認定資格試験を受けようと考えている方に向けて、何かの参考になれば幸いです。

システムの監視は安定した運用を維持するために欠かせない要素です。 モニタリングの一環として「アラーティング（警告通知）」を整備することで、システムの異常を早期に検出して適切な対応を取ることでダウンタイムの回避やパフォーマンスの最適化を図ることができます。今日、Grafana は OSS として公開されているダッシュボードツールのデファクトスタンダードとなっています。 Grafana はメトリクスの可視化やデータ分析の機能だけでなく、アラート機能を活用することでシステムの異常をリアルタイムに検出し、担当者に迅速に通知することが可能です。 最新の Grafana バージョンでは、アラート機能が大幅に強化され複雑な条件設定や通知チャネルの多様化に対応しています。Grafana Alert は単純なクエリや閾値に加え、ポリシを設定することで通知のタイミングを柔軟に制御することができます。今回のブログでは、Grafana Alert の機能について基本的な仕組みやアラートの制御方法について整理したいと思います。

Kubernetes には Pod の配置を制御する機能があります。 Pod の配置制御とは、任意の Pod を特定のノードにスケジュールしたり、逆に特定のノードに対して Pod をスケジュールさせないようにコントロールすることです。最も簡易的な方法として、Node Selector を使用することで任意の Pod を所定のノードにスケジュールすることができます。 また、Node Selector に加え、より細やかな制御が可能な Node Affinity を使用することもできます。Node Selector および Node Affinity が、ある Pod を特定のノードにスケジュールさせるために使用されるのに対し、Pod をあるノードから遠ざけたい、または特定のノードをワークロードから隔離したいという要件に対しては Taints/Tolerations という機能が用意されています。 Taints と Tolerations は互いに作用しあい、Pod が不適当なノードにスケジュールされるのを防ぎます。Node Affinity の場合は、未指定の場合、どのノードにでも Pod をスケジュール可能ですが、Taints/Tolerations の場合は、指定しない限りそのノードに Pod がスケジュールされることはありません。Taints/Tolerations は、例えば Production 用のノードには他の Pod をスケジュールさせたくない場合や、GPU（Graphics Processing Unit） や FPGA（Field Programmable Gate Array） 等の特殊なデバイスを持つノードには特定の Pod 以外をスケジュールさせたくないといった場合に有効です。今回のブログでは、Taints/Tolerations による Pod の配置制御とノードの隔離策についてまとめたいと思います。

昨年 12 月 2 日 - 6 日までの 5 日間に渡り、米 Las Vegas にて AWS re:Invent が開催されました。 今回は、次世代 SageMaker の発表や Bedrock・Knowledge Bases の機能強化、Nova のマルチモーダル画像・動画生成モデルの提供開始等、生成 AI に関する話題が盛りだくさんでした。中でも個人的に興味深かったのが EKS Auto Mode の発表です。 これまでの EKS は、Control-Plane に関してある程度の機能がマネージドに提供されているものの、Google Kubernetes Engine（GKE） と比較してネイティブな Kubernetes を運用しなければならない印象でした。また、手動でのクラスタアップグレードが必要な上、Data-Plane（ワーカーノード）の運用自動化も提供されておらず、ある程度インフラの知識を持ったエンジニアによる戦略的なメンテナンス作業が必要でした。EKS Auto Mode では Kubernetes に必要なコンピュートリソース、ストレージシステム、ネットワーキング機能のプロビジョニング自動化等、従来の EKS と比較してクラスタの管理コストを大幅に下げることが期待できます。今回は、そんな EKS Auto Mode の特徴や仕組みについて、個人的な所感を交えつつ紹介したいと思います。