はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン講義資料

コンテナコンテナオーケストレーション IBUFOBJOUFSO !

この講義で学んでほしいこと • コンテナの概要 • コンテナオーケストレーションの概要 • コンテナオーケストレーションのデファクトスタンダードであるKubernetesの特徴と機能 • インターンの中でKubernetesを使うために最低限の操作⽅法
IBUFOBJOUFSO !

コンテナ IBUFOBJOUFSO !

世はまさに⼤コンテナ時代 • ここ数年でエンタープライズの環境でもコンテナが利⽤されている • はてなでもほとんどのアプリケーションがコンテナで動いている(ECS) • コンテナオーケストレーションとしてはKubernetesがデファクトスタンダードで、各クラウドがKubernetesサービスを提供し
ている IBUFOBJOUFSO !

なぜコンテナ環境が採⽤されるのか • ポータビリティ（可搬性）の向上と環境再現性 • Build once, Run anywhere • コンテナじゃないときは、⾃分の環境では動くのに...とか、
テスト環境では動くのに...というのが起きやすい • 確実な環境分離と依存関係の明確化 IBUFOBJOUFSO !

なぜコンテナ環境が採⽤されるのか • 開発者の⽣産性向上 • ⾼速な開発サイクル • 環境構築の簡素化 • アプリケーション運⽤の効率化 •
コンテナオーケストレーションとしての役割現代のアプリケーション開発でコンテナは⽋かせないものになっている IBUFOBJOUFSO !

コンテナとは IBUFOBJOUFSO !

コンテナで実現したいこと • 仮想化 • 可搬性 (portability) を⾼く保つこと • ⾼速(not performance)‧低コストであること
これらを実現するのが、プロセスの隔離とコンテナイメージによる環境の構築 IBUFOBJOUFSO !

プロセスの隔離 • コンテナ技術の根幹となる概念の1つ • あるプロセスから⾒えるリソース‧利⽤可能なリソースを制限する • プロセス間の⼲渉がなくなり、複数のプロセスを安定して稼働させられる •
不要なリソースを利⽤させないことで、安全性を⾼められる IBUFOBJOUFSO !

コンテナイメージ • 隔離されたプロセスの実⾏環境 • 次のようなものが含まれる • プロセスが動作するために必要なライブラリ等をまとめたファイルシステム • 環境変数など実⾏時の設定
• その他のメタ情報 IBUFOBJOUFSO !"

コンテナを実現する技術 IBUFOBJOUFSO !!

コンテナを実現するプロダクト • 2000年: FreeBSD jails • 2008年: Linux Containers (LXC)
• 2013年: Docker • 2019年: Podman これらのプロダクトも、概ね以降で紹介する技術 (や、相当の機能) を組み合わせて実現されています IBUFOBJOUFSO !"

リソースの制限 • コンテナはプロセスが利⽤できるリソースを制限する技術を組み合わせて実現されている • 何を制限するかによって複数の要素技術がある • リソースの隔離(可視性): Namespace (PID,
Mount, User, cgroup...) • リソースの利⽤上限: cgroup • 特権‧システムコール等: Capability, seccomp, ... IBUFOBJOUFSO !"

Namespace • Linux Kernel の持つ機能 • Namespace ごとにリソースを隔離して、Namespace 内のプロセスに対して独⽴した環境に⾒せる
• それぞれのプロセスが⼲渉することがなくなる • どのリソースを隔離するかによって様々な Namespace が存在する • PID, Mount, User, Network, IPC, UTS, Time, cgroup IBUFOBJOUFSO !"

PID Namespace • プロセス ID 番号空間の隔離 • 名前空間内で最初のプロセスは PID 8
ubuntu@utm:~$ ps PID TTY TIME CMD 1889 pts/0 00:00:00 bash 2711 pts/0 00:00:00 ps # unshareίϚϯυͰ෼཭ ubuntu@utm:~$ sudo unshare "#pid "#fork "#mount-proc ps PID TTY TIME CMD 1 pts/0 00:00:00 ps IBUFOBJOUFSO !"

User Namespace • UID/GID を分離する • Capability (後述) を分離する •
異なる Namespace で同じ UID のユーザを作成できる • ホストからは⼀般ユーザ、コンテナ内では root というユーザが作成できる • マッピング IBUFOBJOUFSO !"

その他のNamespace • Mount: マウントポイントを分離する • Network: ネットワークデバイス、ルーティングテーブル、IP アドレス、ポート番号などを隔離する • Time:
ホストとコンテナの時間を分離する • IPC: 共有メモリを分離する • UTS: ホスト名とドメイン名を分離する IBUFOBJOUFSO !"

cgroup • cgroupは、プロセスグループに対してCPU、メモリ、ディスクI/Oなどのリソースの使⽤量を制限、監視、優先順位付けをするLinuxカーネルの機能 • 階層構造を持っており、各ノード(cgroupの階層)がリソースグループを表す • cgroup
Namespaceにより、コンテナ内のプロセスはホストOS全体の cgroup階層を⾒るのではなく、⾃⾝に割り当てられたcgroup階層のサブツリーをルートとして認識する IBUFOBJOUFSO !"

Capability • 特権の細分化 • ネットワーク操作など、特定の操作を⾏うために特権が必要となることがある • 特定の操作のためにあらゆる特権を取得するのは過剰 • pingバイナリに CAP_SYS_BOOT(システムの再起動)を付与してしまった
• pingコマンドの実⾏のために特権を取得すると、この特権で PC の再起動までできるようになってしまった • もちろんping コマンドの中に再起動処理のロジックが⼊っていなければできないけれど、権限としてはできる IBUFOBJOUFSO !"

Capability • Linux Kernel では操作の種類に応じた権限として、Capability という概念があり、プロセスに対して許可する権限を個別に選択できる • Capabillityは"鍵"のようなもので、実装という"ドア"とセットで機能する •
pingは、ICMPパケットを直接送受信するために、rootでしか使えないRAWソケットを利⽤する • pingバイナリに、この特権処理を許可するCAP_NET_RAWというCapabilityのみを付与し、pingは⼀般ユーザでも実⾏可能になる • pingバイナリにはシステムを再起動する権限であるCAP_SYS_BOOTのような他の強⼒な権限は付与しない • pingコマンドに脆弱性があっても、システム全体に影響が及ぶリスクを最⼩限に抑えることができる • Capability の⼀覧は man capabilities(7) で確認できる IBUFOBJOUFSO !"

Capability • 特権操作を必要とするプロセスに対しても、特権を渡すのではなく Capability を付与する • Capability によって許可される操作は Namespace
で隔離された範囲に閉じないことがあるので注意する必要がある • コンテナランタイムはコンテナで実⾏するプロセスに対していくつかの Capability をデフォルトで付与する • 設定によって追加の Capability を付与することもできる • Docker の場合 !"cap-add, !"cap-drop, !"priviledged オプションがある IBUFOBJOUFSO !"

seccomp • システムコールの中には、Linux Namespaceでは⼗分に分離できない、あるいはホストシステム全体に影響を及ぼす可能性のあるリソースに⼲渉するものがある • コンテナ内のプロセスからこれらのシステムコールが呼び出されると、コンテナの分離性が損なわれ、ホストシステムにセキュリティ上の影響が及ぶリスクがある • seccomp
はプロセスの発⾏できるシステムコールを制限する仕組みで、コンテナランタイムは seccomp を利⽤してコンテナ内のプロセスがこれらのシステムコールを呼び出すことを防ぐ • Docker でデフォルトで制限されているシステムコールは公式ドキュメントに⼀覧されている • 設定でプロファイルを渡すことによって呼び出しを制限するシステムコールを制御できる • プロファイルとは、許可するシステムコールと拒否するシステムコールを定義したルールセット IBUFOBJOUFSO !!

コンテナイメージ IBUFOBJOUFSO !"

プロセスの実⾏環境 • プロセスが利⽤するライブラリや読み書きするファイルも独⽴していたい • スケーラビリティを確保するためにはこれらが素早く、再現性を持って準備されていたい • これを実現するのがコンテナイメージ IBUFOBJOUFSO
!"

コンテナイメージ • コンテナ化された環境で利⽤するファイルシステムなどをまとめたもの • 主な内容物はコンテナ化されるプロセスから参照される Mount Namespace にマウントされるファイル群の tar
アーカイブ • コンテナ化されるプロセスにとって、この tar アーカイブが/ (ルートディレクトリ)となるようにコンテナランタイムは pivot_rootする IBUFOBJOUFSO !"

Union ファイルシステム • 複数の異なるファイルシステムを重ね合わせて利⽤できる仕組み • OverlayFS などの実装がある IBUFOBJOUFSO !"

Union ファイルシステム • ベースとなる下位ディレクトリ (Lower Dir) に対し、差分を上位ディレクトリ (Upper Dir)
として重ね合わせる • コンテナイメージに含まれるファイルシステムは Lower Dir、コンテナ上で変更されるファイルシステムを Upper Dir とする • Lower Dir は変更されないので1つのコンテナイメージを複数のコンテナインスタンスで共有できる • 変更を個々のコンテナインスタンス毎の Copy on Write レイヤー (Upper Dir) に適⽤する IBUFOBJOUFSO !"

コンテナイメージの構造を覗く FROM ubuntu RUN echo "hoge" > hoge.txt RUN rm
hoge.txt $ docker build . -t sample 作成したイメージを出⼒して解凍する $ docker save sample > image.tar $ mkdir /tmp/images $ tar xf image.tar -C /tmp/images $ ls -l /tmp/images total 32 drwxr-xr-x@ 3 rskmm0chang wheel 96 7 14 12:54 blobs -rw-r"#r"#@ 1 rskmm0chang wheel 362 1 1 1970 index.json -rw-r"#r"#@ 1 rskmm0chang wheel 1067 1 1 1970 manifest.json -rw-r"#r"#@ 1 rskmm0chang wheel 31 1 1 1970 oci-layout -rw-r"#r"#@ 1 rskmm0chang wheel 89 1 1 1970 repositories IBUFOBJOUFSO !"

イメージレイヤー blobs以下にDockerﬁle の命令毎にレイヤーが分かれている $ tree /tmp/images/ /tmp/images/ ├── blobs │
└── sha256 │ ├── 081fb1efc91eea477727e7966405f2e3038e2f283672dda79108e305e1d14e09 │ ├── 176b61970a68fab10ed0567af1cb59479f6d50436043cf533b123ad1e485e5c9 │ ├── 520724c855391393f7903c957f7a8d4c363fb6c216f53374f69f55c338e46aca │ ├── 7e06715b212add1e8fab9603a4c3954986ea7f8a5b20a83a559af215c16e8766 │ ├── 88d4446cbfd41e9e3e5225c78c6e068d3104726e320b92ec1d62d81fd3641b4e │ ├── 961ef2cb6a6eec47b257f88e92a47dcabb5df1b010acc4cd41bc153c3fe6c98a │ ├── a353043666c367fcf0ccba8b0a0dc23b4bd9625ea7ceefeb8dbc0917d9b4061e │ └── fcecd6f30cfb23f719076bb2bae17b876968f9bebcc1821d5f54cf594c9f63b5 ├── index.json ├── manifest.json ├── oci-layout └── repositories IBUFOBJOUFSO !"

blobs • 下位のレイヤーに対しての差分がまとめられている • 以下のblobsの中⾝を⾒てみる # vΛ͚ͭͯల։ $ tar xvf
blobs/sha256/081fb1efc91eea477727e7966405f2e3038e2f283672dda79108e305e1d14e09 -C /tmp/layer_content x hoge.txt IBUFOBJOUFSO !"

blobs whiteout • ファイルの削除は whiteout ﬁle によって表現される • ファイルを削除したときは .wh.(ϑΝΠϧ໊)
という空ファイルが作られる • ディレクトリを削除したときは .wh.(σΟϨΫτϦ໊) という空ファイルが作られる • ディレクトリの内容をすべて削除した場合、そのディレクトリ全体を不透明（opaque）にするためにopaque whiteout ﬁle(.wh!"wh!"opq)が作成される IBUFOBJOUFSO !"

whiteout # vΛ͚ͭͯల։ $ tar xvf blobs/sha256/a353043666c367fcf0ccba8b0a0dc23b4bd9625ea7ceefeb8dbc0917d9b4061e -C /tmp/layer_content x
.wh.hoge.txt IBUFOBJOUFSO !"

レイヤーキャッシュ # syntax=docker/dockerfile:1 FROM golang:1.23-bookworm AS builder WORKDIR /services/blog COPY
go.mod go.sum ./ # ͕͜͜มߋ͞Εͨ৔߹͸ ↓ ͷ෦෼Λ࠶࣮ߦ RUN go mod download COPY . . RUN "#mount=type=cache,target=/root/.cache/go-build \ make build • コンテナイメージのビルド時には Lower Dir に対する変更を Upper Dir として新しいレイヤー⽤の tar アーカイブを作成する • ⼀度実⾏した命令は Lower Dir として残っているので、Upper Dir による変更だけを⾏えばよく、レイヤーキャッシュが利⽤できる IBUFOBJOUFSO !!

⾼レベルランタイム • containerd, CRI-O など • コンテナイメージや複数台のコンテナを管理する • ユーザインタフェースとなるツールや、コンテナオーケストレーションツールと通信する
• CRI (Container Runtime Interface) という規格がある • 低レベルランタイムと通信してコンテナを起動する‧低レベルランタイムにコンテナ環境の設定を送信する • Docker は低レベルランタイムとの通信に containerd を利⽤している IBUFOBJOUFSO !"

低レベルランタイム • runc, gVisor など • 個々のプロセスを起動し、Namespace を隔離してコンテナとして実⾏する •
OCI Runtime Spec (Open Container Initiative Runtime Speciﬁcation) によって標準的な仕様‧挙動が定義されている IBUFOBJOUFSO !"

ランタイム IBUFOBJOUFSO !"

実践的なコンテナイメージの作成 IBUFOBJOUFSO !"

1コンテナ 1プロセス • 単⼀の機能として分離して⽔平スケールしやすくするため • 再利⽤性、透明性を⾼める • 依存関係を減らす • PID
1問題への対策にもなる • PID Namespaceのところで話した話題 • LinuxにおいてPID eは特殊な役割がある • 通常ではinitや、systemdなどが担っている IBUFOBJOUFSO !"

ステートレスでイミュータブルにする • 状態を持たず、不変 • 実⾏しているコンテナ内でアプリケーションを変更しない • 永続データはコンテナ外部のコンポーネントに任せる • ログは stdout/stderr
に出⼒する • ログをファイルに書き出さない • コンテナオーケストレーションはstdout/stderrをそのコンテナのログとして⾒る(docker logsなども) IBUFOBJOUFSO !"

イメージは軽量にする • 実⾏に必要な依存関係のみを持つイメージを作成する • 軽量なので実⾏までのコストが⼩さくなる。依存関係が減ると攻撃されうる対象も減る。 • 軽量なベースイメージを選択する • -slim
な ﬂavor や distroless をベースとして、必要なランタイムとアプリケーションだけインストールする • Seekable OCI でイメージを遅延読み込みすることも可能だが、変換が必要 IBUFOBJOUFSO !"

適切なベースイメージを選択する • イメージを作成する上で、ベースイメージを正しく選択することは重要 • 開発元の公式イメージや、コンテナレジストリで veriﬁed となっているイメージを選択する • Alpine Linux
を避ける • glibc を採⽤していないので互換性やパフォーマンスの問題が起こることがある • Alpine Linuxだとビルドが困難なものもある IBUFOBJOUFSO !"

コンテナのユーザは⼀般ユーザにする • User namespace の分離と適切なマッピングを指定しない場合、コンテナの root はホストの root に対応する
• コンテナ内の脆弱性で root 権限を取得された場合、影響がホストの root にまで及んでしまうことも • Dockerﬁle の USER 命令でコンテナを実⾏するユーザを指定する IBUFOBJOUFSO !"

設定値を環境変数に格納する • コンテナイメージを作り直すことなく動作を変更できる • デリバリータイムの削減 • 複数の環境で同じ Docker イメージが使える •
The Twelve-Factor App で提唱されている IBUFOBJOUFSO !"

シークレット値をコンテナイメージに含めない • コンテナイメージ経由でシークレットが漏洩する可能性がある • シークレットの更新のためにコンテナイメージを再度⽣成する必要がある • 代わりに以下のような⽅法をとる • コンテナ起動後にネットワーク経由で取得する
• 環境変数経由でコンテナにシークレットを渡す • The Twelve-Factor App ではこの⽅法を推奨している • コンテナがマウントされるボリュームに書き込む IBUFOBJOUFSO !!

Graceful Shutdown コンテナに限らないけれど、コンテナ環境ではアプリケーションのライフサイクルが短くなりやすい • アプリケーションを適切に終了させる • データの不整合が起きないように、など、アプリケーションをきちんと⽌める • SIGTERMに対応させる •
コンテナオーケストレーションでのオートスケールへの対応にもなる • アプリケーションの中にはSIGTERM以外のときがあるので注意 • nginxとかphp-fpmはSIGQUIT • DockerﬁleのSTOPSIGNALでGraceful Shutdownのシグナルを変えることも可能 • https://github.com/nginx/docker-nginx/blob/master/Dockerﬁle-debian.template#LÇÉÉ IBUFOBJOUFSO !"

コンテナを動かす環境 • Dockerの登場でコンテナが簡単に使えるようになった • 本番環境で扱うにはオペレーションが⾜りない • デプロイ • 復旧⼿段 •
スケール IBUFOBJOUFSO !"

コンテナオーケストレーション登場 IBUFOBJOUFSO !"

...休憩... IBUFOBJOUFSO !"

コンテナオーケストレーションとは IBUFOBJOUFSO !"

コンテナオーケストレーションの⽬的 • ⾃動化による管理コスト削減 • コンテナのライフサイクルを⾃動化し、⼿間とコストを削減する • コンテナ環境の⾼い可⽤性を維持 • コンテナやノードの障害発⽣時に、アプリケーションの継続的な稼働を可能にする
• コンテナ同⼠の接続 • 複数のコンテナが協調して動作するために必要なネットワークを⾃動的に設定し、コンテナ同⼠が安全かつ効率的に通信できるようにする IBUFOBJOUFSO !"

コンテナオーケストレーションツールが持つ主な機能 • コンテナ配置のスケジューリング • コンテナをどのノードに配置するか • 負荷分散/サービスディスカバリー • クラスタ内のコンテナ間の負荷分散
• セルフヒーリング/ヘルスチェック • コンテナのヘルスチェックと問題発⽣時への⾃動復旧 • オートスケーリング • 負荷に応じたコンテナのスケールイン‧アウト IBUFOBJOUFSO !"

コンテナ配置のスケジューリング • コンテナの起動数を指定し、その数だけコンテナを⽴てる • システムの負荷やコンテナの起動条件をみて、どのマシンにコンテナを⽴てるかを⾃動で選択する • フィルターとスコアリング IBUFOBJOUFSO !"

負荷分散/サービスディスカバリー • 複数のコンテナに負荷を分散して可⽤性を⾼める • サービスディスカバリー • 動的にコンテナが⼊れ替わるクラスター内で特定のコンテナを⾒つけて通信するための仕組み • コンテナは⽣存期間が⽐較的短く、IPアドレスも頻繁に変わ
る IBUFOBJOUFSO !"

セルフヒーリング • マシンに障害が発⽣した場合 • 正常なマシンにコンテナを配置し直す • コンテナに障害が発⽣した場合 • 必要な分だけコンテナを⽴て直す •
コンテナ障害を検知するためのヘルスチェック IBUFOBJOUFSO !"

オートスケーリング複数のコンテナのスケーリングを、負荷状況に応じて⾃動で⾏う仕組み • コンテナのスケールイン‧スケールアウト（コンテナ数の増減） • コンテナのスケールアップ‧スケールダウン（CPUやメモリの割り当ての増減） IBUFOBJOUFSO
!!

コンテナオーケストレーションたち • Docker Swarm • Apache Mesos • Kubernetes •
Amazon Elastic Container Service(ECS) AWSの優位性をベースにECSも使われているが、商⽤環境(オンプレ含む)ではKubernetesがデファクトスタンダード IBUFOBJOUFSO !"

Kubernetesとは IBUFOBJOUFSO !"

Kubernetesとは • Kubernetes, K,s • Googleの内製コンテナ管理ツールBorgをOSS化したもの • OSSになる前からGoogleの⼤規模環境で利⽤されていたので、概念が洗練されていた • パブリッククラウドでサービスが提供されている
• Amazon Elastic Kubernetes Service(EKS) • Google Kubernetes Engine (GKE) • Azure Kubernetes Service (AKS) • ⾼い拡張性、エコシステムが充実 • コントローラ作成やAdmission Webhookなど IBUFOBJOUFSO !"

Kubernetesで何ができるのか？コンテナオーケストレーションツールとして持つべき機能を⼀通り兼ね備えている • 宣⾔的な構成管理 • コンテナ配置のスケジューリング • 負荷分散/サービスディスカバリー • セルフヒーリング/ヘルスチェック
• オートスケーリングここからはKubernetesの⾔葉でこれらを説明していく IBUFOBJOUFSO !"

宣⾔的な構成管理 Kubernetesは宣⾔的な構成管理を実現している • 期待する状態を設定ファイル(Manifest)に記述する • 設定ファイルを適⽤すると、以前の状態に依存せずに宣⾔した状態になる • 設定ファイルの内容と現状に差分があるかどうかを⾒て、差分があれば、その状態にする
• Reconciliation Loop IBUFOBJOUFSO !"

Kubernetesの構成 IBUFOBJOUFSO !"

Cluster 引⽤元: https://kubernetes.io/docs/concepts/overview/components/ IBUFOBJOUFSO !"

Cluster • control PlaneとNodeで構成 • control Plane • kube-apiserver •
etcd • kube-scheduler • kube-controller-manager • Node • kubeletがkube-apiserverとやり取り • コンテナを実⾏するためのコンピューティングリソースの集まり • Data Planeと⾔ったりもする • 詳細は後述 IBUFOBJOUFSO !"

control Plane • Kubernetesの中枢となるコンポーネント • 各クラウドのマネージドサービスでは、まさにマネージドなところ • kube-apiserverを介して、各コンポーネントが機能する IBUFOBJOUFSO
!"

Node • Data Plane • 複数のPod(コンテナの集まり)を実⾏するためのコンピューティングリソース • 物理 or
仮想のサーバー • ノードでkubeletが起動し、API Serverとやりとりをする • K`s⾃体にはノードをスケールさせる仕組みはない • サードパーティ(cluster-autoscaler, Karpenter)を利⽤する IBUFOBJOUFSO !"

Pod • デプロイの最⼩単位 • Podは1つ以上のコンテナから構成される • ストレージとネットワークを共有する • Network Namespace
• Mount Namespace IBUFOBJOUFSO !!

複数のコンテナ • Podは1つ以上のコンテナ群 • 1コンテナ1プロセス • ひとつのPodに複数のコンテナ • メインのコンテナとそれを⽀えるコンテナ
• (例) Proxy, ログ転送, 監視エージェント • 内部的にpauseコンテナが動いていて、 Namespaceの共有などを⾏う • PodのStatusとして⾒えないが、ノードからは⾒える特殊なコンテナ引⽤元: https://www.ianlewis.org/en/ almighty-pause-container IBUFOBJOUFSO !"

Kubernetesのリソース IBUFOBJOUFSO !"

リソースのカテゴリあまりカテゴリを意識することはないけれど、説明しやすいので、いったん分けて話していきます • Workloads コンテナの実⾏に関するリソース • Service コンテナを外部公開するようなエンドポイントを提供するリソース • Conﬁg＆Storage
設定‧機密情報‧永続化ボリュームなどに関するリソース • Cluster セキュリティやクォータなどに関するリソース • Metadata クラスタ内の他のリソースを操作するためのリソース Namespaceという仮想的なクラスタの分離機能 IBUFOBJOUFSO !"

Workloadsカテゴリコンテナの実⾏に関するリソース • Pod 1つ以上のコンテナから構成されている Pod内に含まれるコンテナは同じネットワーク内に存在し同⼀IPを持つコンテナ同⼠はlocalhostで通信可能 • ReplicaSet Podのレプリカを作成して指定した数のPodを維持する
同じコンテナイメージのコンテナが複数がPodが展開される IBUFOBJOUFSO !"

Workloadsカテゴリ • Deployment 複数のReplicaSetを管理してローリングアップデートやロールバックなどを可能にする Deploymentの機能としてローリングアップデートやロールバックを⾏うこの機能があることで、K,sだけでもデプロイ管理しやすい
IBUFOBJOUFSO !"

Workloadsカテゴリ • Statefulset Volumeを扱いやすくしたり、Pod名を固定したりして、ステートフルなアプリケーションを動かしやすくしたリソース • DaemonSet すべてのノードにPodを配置させるためのリソース • Job
コンテナを利⽤してワンオフの処理を実⾏させるリソース • CronJob スケジュールされた時間にjobを実⾏するリソース IBUFOBJOUFSO !"

Serviceカテゴリコンテナを外部(クラスタ内外)開するようなエンドポイントを提供するリソース受信したトラフィックを複数のPodにロードバランシングする • Service • L)ロードバランサ • サービスディスカバリ •
Ingress • L;ロードバランサ IBUFOBJOUFSO !"

ConfigMap/Secret アプリケーションの設定をリソースとして管理でき、アプリケーションと設定を分離できる • ConfigMap • 機密性のないデータをキーと値のペアで保存する • 環境変数の管理もできる • Secret
• ConfigMapと機能はほぼ同じ • 機密性のあるデータをキーと値のペアで保存する • といっても実はただのBaseYZなので、丸⾒えに近い • secretは使わずに、Podにmountさせるのがベストではあるが、やや⼿間 • https://github.com/aws/secrets-store-csi-driver-provider-aws IBUFOBJOUFSO !"

Kubernetesクラスタ内の通信少しServiceまわりを掘り下げていきます • 同じPod内のコンテナに通信する場合はlocalhost宛に通信する • 別のPodに通信する場合はPodのIP宛に通信する • PodのIP宛の通信は可能だがアプリケーションからIPを指定すると実運⽤上で課題が発⽣する • PodのIPはPodが⼊れ替わる度に異なるIPが割り当てられる
• Podが停⽌した場合にサービス断が発⽣する • オートスケールなどPodの数が流動的な場合に破綻するこれらを解決するのがServiceリソース IBUFOBJOUFSO !"

Service ロードバランサ • kube-proxyというコンポーネントの機能 • iptablesで実現している • 他の実装もあるが、デフォルトはiptables • 複数のPodに対するトラフィックのロードバランシング(負荷分散)を⾏う
• ロードバランシングの⼊り⼝となるエンドポイントを提供 • エンドポイントには単⼀の仮想IPが割り当てられる • エンドポイントの種類は⽤途によって様々 • ClusterIP (内部向け) • NodePort (外部向け) • LoadBalancer(外部向け) IBUFOBJOUFSO !"

Service サービスディスカバリ • 動的にPodが⼊れ替わるクラスター内で情報を登録、発⾒するための仕組み • クラスタ内DNSの利⽤が推奨されている • ロードバランシングの⼊り⼝となるエンドポイントがクラスタ内DNSに⾃動的に登録される
• [SERVICE_NAME]. [NAMESPACE].svc.cluster.localという形式で DNS Aレコードに割り当てられる • (例) account.hatena- intern.svc.cluster.local • 同じNamespace内であれば、account、違う Namespaceの場合はaccount.hatena-internでも名前解決できる IBUFOBJOUFSO !!

Ingress • Ingress • L)のロードバランサ • Kubernetes⾃体にはIngressの実装がなく、インターフェイスのみ • aws-load-balancer-controller, ingress-nginx,
etc • HTTPSの終端として証明書を指定可能 • Secretは証明書も管理でき、それを指定できる IBUFOBJOUFSO !"

リソース管理 IBUFOBJOUFSO !"

Manifest • リソース定義ファイル • yamlで書くことが多いがjsonでも可能 • kubectl apply -f <manifest>
によってK=sクラスタに適⽤ • コントローラがリソースの状態を⾃律的にマニフェストの内容に近づける • Reconciliation Loop IBUFOBJOUFSO !"

Manifestのサンプル(Deployment) apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app:
nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 IBUFOBJOUFSO !"

Manifestのサンプル(Service) apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector:
app: nginx ports: - protocol: TCP port: 80 targetPort: 80 IBUFOBJOUFSO !"

リソース制限 • Podに対して割り当てるCPUやメモリの制限を⾏うことができる • cgroup • 要求と制限 • requests(要求)とlimits(制限)を指定でき
る • ノードにPodを配置する際に考慮される • requestsの指定がない場合は判断のしようがないので、どこかのノードに詰め込まれる spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" IBUFOBJOUFSO !"

ヘルスチェック • Podが正しく動作しているか確認するための仕組み • Liveness Probe • アプリケーションが起動し、コンテナが正しく動作しているかどうか • チェックが通らなかったときはPodを再起動する
• Readiness Probe • Podがリクエストを受け付ける準備ができているかどうか • チェックが通らなかったときにはServiceのendpointのリストから当該Podが削除される • Startup Probe • 起動時にしか実⾏されない • Podの起動に時間がかかるような場合に、Liveness Probeの前に実⾏される • Podが正常に起動したことを確認するチェック IBUFOBJOUFSO !"

可⽤性と拡張性 IBUFOBJOUFSO !"

可⽤性(Availability) • セルフヒーリング • ReplicaSetがコンテナのプロセス監視を⾏う • チェックに失敗するとManifestで設定したレプリカ数を維持するように働く • Node障害時にもPodを正常なNodeにスケジ
ュールし直す IBUFOBJOUFSO !"

負荷に対する拡張性(Scalability) • ⽔平オートスケール • Horizontal Pod Autoscaler (HPA) • CPU等のメトリクスを参照してPodのレプリカを⾃動で追加する
• 垂直オートスケール • Vertical Pod Autoscaler (VPA) • Kubernetesの内部リソースではなく、個別に対応は必要 • CPU, メモリの使⽤量を分析してリクエスト値を提案したり⾃動的に更新したりする • Kvsの内部リソースではないので注意 IBUFOBJOUFSO !"

ハンズオンで利⽤するツール紹介 IBUFOBJOUFSO !!

Minikube • ローカル環境でKubernetesのクラスターを⽴ち上げるのにオススメ https://minikube.sigs.kHs.io/docs/start/ • Kubernetesのバージョンを指定してクラスターを構築できる • 他にもkindといったツールなどでもローカルでクラスター構築が可能
• kindは軽量なのでCIでも使われる IBUFOBJOUFSO !"

Kustomize • https://github.com/kubernetes-sigs/kustomize • K7sのマニフェストの構成をカスタマイズするためのツール • Dev, Stg, Prd等の複数の環境分Manifestを書くのは冗⻑なので、共通のベースとなるマニフェストを作りつつ環境毎の差分をパッ
チファイルとして管理できるようになる • kustomization.yaml にどのマニフェストを使うか、secretや conﬁgの設定などを記述する IBUFOBJOUFSO !"

Skaﬀold • https://skaﬀold.dev/ • ファイルの変更を検知してコンテナイメージのビルド、KHs環境へ反映するツール • skaffold.yaml に対象となるファイル、dockerイメージ、マニフェストを記述する
IBUFOBJOUFSO !"

Kubernetesハンズオン IBUFOBJOUFSO !"

アジェンダ • 第1部 Hatena-Intern-./.0環境で遊ぼう • 第2部記法変換サービスの追加 IBUFOBJOUFSO !"

第1部 Hatena-Intern-)*)+環境で遊ぼう IBUFOBJOUFSO !"

この時間はハンズオンです • ⼀緒に⼿を動かして⼿元のKubenetes環境を触ってみましょう • codespaces環境を使います IBUFOBJOUFSO !"

サービスの構成 IBUFOBJOUFSO !"

マニフェストの構成 k8s ├── account │ ├── app.yaml │ ├── config
│ │ └── schema.sql │ ├── db.yaml │ ├── kustomization.yaml │ ├── secret │ │ └── ecdsa-private.pem │ └── test.yaml ├── blog │ ├── app.yaml │ ├── config │ │ └── schema.sql │ ├── db.yaml │ ├── kustomization.yaml │ ├── secret │ │ └── account-ecdsa-public.pem │ └── test.yaml ├── kustomization.yaml ├── namespace.yaml ├── renderer-go │ ├── app.yaml │ └── kustomization.yaml └── system └── sa.yaml • k8s ディレクトリがマニフェスト置き場 • account/blog/renderer-goとマイクロサービスごとにディレクトリを分ける • kustomization.yaml がkustomizeの設定ファイル IBUFOBJOUFSO !"

k"s/blog/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - app.yaml - db.yaml
- test.yaml secretGenerator: - name: blog-app-secret files: - secret/account-ecdsa-public.pem configMapGenerator: - name: blog-app-env-vars literals: - MODE=development - DATABASE_DSN=root@(blog-db:3306)/intern_2025_blog?time_zone=UTC&parseTime=true&loc=UTC - ACCOUNT_ADDR=account:50051 - RENDERER_ADDR=renderer-go:50051 - name: blog-test-env-vars literals: - TEST_DATABASE_DSN=root@(blog-db:3306)/intern_2025_blog_test?time_zone=UTC&parseTime=true&loc=UTC - name: blog-db-schema-config files: - config/schema.sql IBUFOBJOUFSO !"

確認 % make up • 8080番ポートは⾃動でポートフォワードされるようになっていますが、ポートフォワードされていない場合、別のターミナルを開き、以下のコマンドでポートフォワードできます。 % kubectl port-forward
service/blog 8080:8080 # ϩʔΧϧͷ8080ϙʔτ΁ͷ௨৴Λ blog service ͔Βෛՙ෼ࢄ͞Ε͍ͯΔpodͷ8080ϙʔτʹసૹ͢Δ もしくは再度make upしてください。 Podが起動すると、⾃動でブラウザが開くので開いてブログを作成してみましょう。開かない場合、vscodeのterminalのPORTSタブから8080ポートを追加してあげてください。 IBUFOBJOUFSO !!

サービスが起動していることを確認する contextの切り替え % kubectl config use-context hatena-intern-2025 % kubectl get
pods IBUFOBJOUFSO !""

Podが起動する様⼦を⾒よう • services/blog/templates/index.html を書き換えると Skaﬀoldが反応するはず別の端末で実⾏してPodの状態を⾒る % kubectl get pods
-w % kubectl describe pods IBUFOBJOUFSO !"!

デバッグ # Podͷৄࡉ৘ใͷදࣔɻpod͕ىಈ͠ͳ͍৔߹͸ಛʹ"Events:"ཝʹ஫໨ % kubectl describe pod blog # ωʔϜεϖʔε্ʹ͋ΔϦιʔεͷ৘ใΛදࣔ
% kubectl get all # ىಈ͍ͯ͠ΔPodͰγΣϧΛىಈ͢Δ % kubectl exec -it svc/account -c account !" /bin/sh Pod(コンテナ)に⼊ったら - 起動しているプロセスは？ ! ps - blogサービスにアクセス ! wget -q -O - blog:8080 - ! nslookup blog IBUFOBJOUFSO !"#

第2部記法変換サービスの追加 IBUFOBJOUFSO !"#

記法変換サービス renderer • services/renderer-ts にある実装をK*s上で動かす • デフォルトでは services/renderer-go が動いている •
k8s/renderer-go を参考に、k8s/renderer-ts を追加 IBUFOBJOUFSO !"#

対応するファイル • 追加するファイル • k8s/renderer-ts/kustomization.yaml • k8s/renderer-ts/app.yaml • 編集するファイル •
skaffold.yaml • k8s/kustomization.yaml • k8s/blog/kustomization.yaml IBUFOBJOUFSO !"#

ファイルの追加 % cp -R k8s/renderer-go k8s/renderer-ts % sed -i -e
's/renderer-go/renderer-ts/g' k8s/renderer-ts/*.yaml • k8s/renderer-go ディレクトリをコピーして k8s/ renderer-ts を作成 • マニフェスト内の renderer-go を renderer-ts に置き換え IBUFOBJOUFSO !"#

skaﬀoldの編集 skaﬀold.yaml apiVersion: skaffold/v4beta13 kind: Config metadata: name: hatena-intern-2025 build:
artifacts: # (snip) - image: hatena-intern-2025-renderer-go context: services/renderer-go - image: hatena-intern-2025-renderer-ts # ! context: services/renderer-ts # ! local: # (snip) • services/renderer-ts のdockerイメージのビルドとk2sクラスタへの反映がされるようにする IBUFOBJOUFSO !"#

マニフェストの編集 k"s/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization namespace: hatena-intern-2025 resources: -
namespace.yaml - account - blog - renderer-go - renderer-ts # ! IBUFOBJOUFSO !"#

マニフェストの編集 k"s/blog/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization # (snip) configMapGenerator: -
name: blog-app-env-vars literals: - MODE=development - DATABASE_DSN=root@(blog-db:3306)/intern_2025_blog?time_zone=UTC&parseTime=true&loc=UTC - ACCOUNT_ADDR=account:50051 - RENDERER_ADDR=renderer-ts:50051 # ! - name: blog-test-env-vars # (snip) • blogサービスの記法変換サービスへの向き先をrenderer-goからrenderer-tsに変える IBUFOBJOUFSO !"#

Podが正常に起動しない場合 • kubectl get pods を実⾏して各Podが正しく起動しているかどうか確認する • kubectl describe
pod renderer-ts で詳細情報を確認 • なぜ正常に起動しないか原因を探ろう IBUFOBJOUFSO !!"

実際にrenderer-tsが動くことを確認する • kubectl get pods よりすべてのPodが正常に起動していることを確認 • ブログにアクセスし、記事を作成し renderer-ts
サービスが動くことを確認 IBUFOBJOUFSO !!!

変更点をpushしておくここらへんはご⾃由にという感じですが、今回の変更点をコミットしてpushしておき、いつでもtypescript実装に変更可能にしておくと今後のインターンに便利だと思います。私はrskmmachang-internfafgっていうブランチでpushしておくので、もし今回のハンズオンで⼿元でうまく動かなかった⼈がいても、このブランチを参考にすることで今後のインターンでts使いたくなった時にrenderer-ts化できると思います。 % git switch -c
rskmm0chang-intern2025 % git add k8s/ skaffold.yaml % git commit -m'rendererΛtypescript࣮૷ʹมߋ' % git push origin rskmm0chang-intern2025 IBUFOBJOUFSO !!"

おまけ1 接続できない場合、ポートの転送ができていない可能性があります。以下のコマンドでポートフォワードしてください # ϙʔτͷసૹ % kubectl port-forward svc/blog-db 3306:3306
IBUFOBJOUFSO !!"

おまけ2 今回のアプリケーションはgRPCを採⽤しているけれど、service での通信で適切ですか？ serviceで接続することはできるが、それが適切かどうか。ヒント: serviceはL(ロードバランサ今回のインターンでは⼤規模な負荷試験はないはずだけど、gRPC のアプリケーションを適切に負荷分散する、となると... IBUFOBJOUFSO !!"

はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン 講義資料

はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン 講義資料

More Decks by Hatena

Other Decks in Technology

Featured

Transcript

はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン講義資料

はてなサマーインターンシップ2025 コンテナ + Kubernetesハンズオン講義資料