はじめに
配属されたチームの環境がKubernetes（EKS）だったため、触ることになりました。
環境構築は担当者が別にいたため、自分がやったのはあくまで既存環境での操作です。
それまでDockerは学習で触ったことがある程度で、インフラやクラウドの実務経験はほぼありませんでした。
Kubernetesという名前と「コンテナオーケストレーションツール」という役割は知っていましたが、実際に触るのは初めてでした。EKS（Amazon Elastic Kubernetes Service）はAWSが提供するマネージドKubernetesサービスで、こちらも業務を通じて初めて知りました。
この記事では、業務で覚えた基本的な概念と操作をまとめていきます。
Kubernetesとは
概要
Kubernetesはコンテナオーケストレーションツールです。
複数のコンテナをまとめて管理・運用するための仕組みを提供してくれます。
Dockerとの違い
Dockerはコンテナイメージをビルドし、コンテナとして実行するためのツールです。
一方KubernetesはそのコンテナをPodという単位で扱い、複数のPodをまとめて管理します。
- Docker：コンテナを1つ動かす
- Kubernetes：コンテナが入ったPodをいくつも束ねて管理する
Kubernetesを使う理由
他にもいろいろとありますが、私が業務を通じて感じたKubernetesを使う主なメリットは以下のとおりです。
- 複数コンテナの一元管理：複数のPodをまとめて管理できる
- 柔軟なスケール：負荷に応じてPodの数を増減できる
- Jobの自動実行：定期的な処理やバッチ処理を自動化できる
- リソース管理：CPUやメモリの使用量をPod単位で制御できる
最初の印象
触り始めて最初に感じたのは「用語が多い」ということでした。
Pod・Service・ConfigMap・Namespaceなど、独自の概念が多く最初は大変でした。
一つひとつ整理しながら、それぞれの役割を理解していきました。
基本的なリソースを整理する
Kubernetesには多くのリソースが存在します。ここでは業務で触れた主なものを整理します。
リソースを国に例えて覚えた
リソースが多く最初は分からなかったため、概念を国に例えて覚えました。
※あくまで個人的な理解の例えです。
| リソース | 国の例え | 説明 |
|---|---|---|
| クラスター | 国 | Kubernetesの管理単位全体 |
| Namespace | 県 | クラスター内のグループ分け |
| Node | 市区町村 | Podが動く実際のサーバー |
| Pod | 建物 | コンテナをまとめた最小デプロイ単位 |
| コンテナ | 建物の中で働く人・機械 | アプリケーションの実行環境 |
| Deployment | 建物を維持・管理する仕組み | Podの数や状態を管理する |
| Service | 道路・通信網 | Pod間・外部との通信を管理する |
| ConfigMap | 建物内のルールブック | 設定情報をPodに渡す |
| Secret | 建物内の金庫 | 機密情報をPodに渡す |
| Job | 期間限定の作業員 | 一度きりの処理を実行する |
| CronJob | 定期的に来る作業員 | 定期的な処理を自動実行する |
この例えをベースに各リソースの役割を説明していきます。
クラスター
Kubernetesで扱うすべてのリソースをまとめた単位です。複数のNodeで構成されており、その中にNamespaceやPodなどのリソースが存在します。
Namespace
クラスター内のリソースをグループ分けする仕組みです。チームや環境（本番・開発など）ごとに分けて管理できます。
Node
クラスター内の実際のサーバー（仮想マシン）です。PodはこのNode上で動きます。普段の操作で直接意識する機会は少ないですが、クラスターの基盤となる存在です。
Pod
Kubernetesの最小デプロイ単位です。1つ以上のコンテナをまとめたもので、同じPod内のコンテナはネットワークやストレージを共有します。アプリケーションは基本的にPod単位で動きます。
コンテナ
アプリケーションとその実行に必要な環境をまとめたものです。Dockerイメージをもとに作られ、Pod内で動きます。1つのPodに複数のコンテナを含めることもできます。
Deployment
Podを管理するリソースです。Podを何個動かすか、どのイメージを使うかなどを定義します。Podが障害で落ちた場合も自動的に再起動してくれるため、安定した運用ができます。
Service
Pod間の通信を管理するリソースです。クラスター外部からのアクセスも管理できます。PodのIPは再起動のたびに変わるため、直接IPで通信するのではなくService名を使って通信することで安定した通信ができます。
ConfigMap
設定情報をPodに渡すためのリソースです。環境ごとに異なる設定値をコードから切り離して管理できます。今回の業務ではYAMLファイルをConfigMapとしてPodにマウントして使用しました。
Secret
機密情報をPodに渡すためのリソースです。ConfigMapと似ていますが、パスワードや接続情報などの秘匿すべき情報を扱います。業務ではRedisクライアントの初期化時に接続情報をSecretで管理していました。
Job / CronJob
一度きりの処理や定期的な処理を自動実行するリソースです。CronJobはLinuxのcronのようなスケジュール実行ができます。
kubectlを使ってみた
kubectlとは
Kubernetesクラスターを操作するためのCLIツールです。
業務では以下の3つのコマンドを主に使用しました。
kubectl get pods
Podの一覧と状態を確認するコマンドです。
操作対象のPod名を確認する際に使用しました。
kubectl get pods
kubectl exec
Pod内に入って操作するコマンドです。
実際にPod内のファイルや環境を確認する際に使用しました。
kubectl exec -it <pod名> -- bash
kubectl config get-contexts / use-context
接続するクラスターのコンテキストを確認・切り替えるコマンドです。
業務ではテスト環境と別クラスターが存在したため、作業前にコンテキストを確認して切り替える操作が必要でした。
誤ったクラスターで操作しないよう、作業前に必ず確認する習慣が大切だと感じました。
# コンテキスト一覧を確認
kubectl config get-contexts
# コンテキストを切り替え
kubectl config use-context <コンテキスト名>
ArgoCDでConfigMapを更新した
ArgoCDとは
ArgoCDはKubernetesのGitOpsツールです。
Gitリポジトリに定義されたマニフェストの状態をKubernetesクラスターに自動的に反映してくれます。
GUIで操作できるため、視覚的にクラスターの状態を確認しやすいのが特徴です。
GitOpsとは
Gitリポジトリを「正しい状態の定義」として扱い、クラスターをその状態に合わせ続ける運用方法です。
ArgoCDはGitの状態とクラスターの状態に差分があると検知して反映してくれます。
テスト時にConfigMapを一時的に変更した
テスト時に設定値を変える必要があり、ArgoCD上で直接ConfigMapを編集しました。
この操作はGitリポジトリには反映されないため、Gitの状態とクラスターの状態に差分が生まれます。
テストが終わったらSyncを実行してGitの状態に戻す、という流れで使用しました。
ArgoCD上でConfigMapを直接編集（テスト用に一時変更）
↓
テスト実施
↓
Syncを実行 → Gitの状態に戻る
使ってみた印象
GUIで操作できるため直感的に使いやすかったです。
またGitの状態とクラスターの状態の差分が視覚的に確認できる点も分かりやすかったです。
つまずいたこと・気づき
① コンテキストの切り替え忘れ
kubectl exec で操作しようとしてもうまくいかない場面が何度かありました。
原因を調べると大体コンテキストの切り替え忘れでした。
複数のクラスターが存在する環境では、作業前に必ずコンテキストを確認する習慣が大切だと感じました。
# 作業前に必ず確認
kubectl config get-contexts
② リソースの概念理解に時間がかかった
Pod・Service・ConfigMap・Deployment・Namespaceなど、
Kubernetes固有のリソースが多く最初は整理するのに時間がかかりました。
ただ一つひとつの役割は明確なので、実際に触りながら覚えていくのが一番の近道だと感じました。
③ 触ってみて感じたこと
最初は概念の多さに圧倒されましたが、触っていくうちにKubernetesがいかに多くのことを自動でやってくれるかが分かってきました。
Podの自動復旧・スケール・Jobの自動実行など、手動でやると大変な運用作業をKubernetesが担ってくれます。
インフラ経験がほぼない状態から始めましたが、便利なツールだという実感は業務を通じて十分に得られました。
おわりに
最初はKubernetesと聞いて難しそうというイメージがありました。
実際に触り始めても、リソースの概念が多く覚えることだらけで分からない場面も多かったです。
ただ業務を通じて一つひとつ触れていくうちに、「少しずつ理解していけば分かる」という感覚が持てるようになってきました。
今回は既存環境での操作が中心だったので、次は以下のことに挑戦してみたいと思っています。
- 環境構築を自分でやってみる
- マニフェストを自分で書いてみる
同じように「初めてKubernetesを触った」というエンジニアの参考に少しでもなれば嬉しいです。