GKE (Google Kubernetes Engine) のネットワーク周りの実装はユーザーの見えないところで変化を続けています。以前は、公式ドキュメントにあるように bridge interface (cbr0) を介してホストマシン (ノード) とコンテナ間でパケットのやりとりが行われていました。しかし、コンテナランタイムを containerd に変更すると (もしくは、コンテナランタイムが dockershim でも比較的新しい時期に作成したクラスターなら？)、見慣れないコンポーネントや使用している CNI plugin の Network Configuration Lists (a.k.a. Chainning) が変わっていることに気付きます。 本記事では、以下の条件の GKE のネットワーク周りの実装について、一部推測も交えながら見ていきます。 GKE version:

コンテナ内でコマンドを実行したときに、コンテナのリソースと思いきやホストのリソースを見ていることがある。 たとえば free コマンドはコンテナでもホストでも同じ実行結果になる。(EC2 の Ubuntu20.04LTS に docker.io 入れて検証) host $ free -h total used free shared buff/cache available Mem: 978Mi 249Mi 152Mi 0.0Ki 576Mi 582Mi Swap: 0B 0B 0B container /# free -h total used free shared buff/cache available Mem: 978Mi 249Mi 152Mi 0.0Ki 576Mi 582Mi Swap: 0B 0B 0B これは 実行しているコマンドが proc などのシステムワイドな情報

はじめに この記事は筆者がKubeCon EU 2021にて発表した「Resource Requests and Limits Under the Hood: The Journey of a Pod Spec」の内容を中心とし、ブログ向けにまとめなおしたものです。 www.youtube.com 日本語でこのリソース要求/制限について内部の仕組みまで踏まえて詳細に書かれた記事はあまりないので、誰かの助けになれば幸いです。 はじめに Kubernetesにおけるリソースの要求と制限 スケジューラーによるスコアリング ノードでのPod作成処理 Requests全体の流れ Limits全体の流れ CRI内部の処理 OCI内部の処理 まとめ Kubernetesにおけるリソースの要求と制限 Kubernetes上でアプリケーションを実行する際、ワークロードの特性に応じて以下のような形で必要なリソ