🏋️‍♀️

Kubernetesの勉強

に公開

先月の自社で行った勉強会の内容まとめ〜概要くらいまで

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

アプリをコンテナ化することで、数十、数百のコンテナを管理する必要がある
これを一つ一つ管理が難しいのでコンテナオーケストレーション技術で、運用・管理を自動化できます

主要な機能、解決する問題

宣言的なリソースの管理 (?)

=>「あるべき状態」を定義する。コンテナの自動配置

負荷分散

=> アプリケーションの間の通信を容易にし、特定のコンテナへのトラフィックが増加している際には、自動的にトラフィックを分散させ、デプロイが安定するようにします

自動更新

=> 「ローリング更新」と呼ばれ、アプリケーションを徐々に、ダウンタイムなしで更新する方法を意味します

自動復旧

=> 障害や定義したヘルスチェックに応答しない等発生した時はコンテナの自動削除。或いは他の通常活動しているコンテナリソースと入れ替え

Dockerとの違いは?

Dockerはアプリケーションを各コンテナに分離する目的で使用
一方、Kubernetesはそれぞれのコンテナを管理するために使われるため、役割にも違いがあります
したがって、複数のDockerを一元管理するのがKubernetesになります。

基本用語

Cluster

Kubernetes全体を管理する単位。複数のノード(仮想または物理マシン)が集まり、アプリケーションのデプロイ、スケーリング、管理を可能にします

コントロールプレーン (Control Plane): クラスター全体を管理する中枢
ノード (Node): ワークロード(アプリケーション)が実行されるマシン

Node

クラスター内でアプリケーションを実行する物理マシンまたは仮想マシン
各ノードはPodをホスト(実行できる状態にする)し、コンテナを実行します

必要なソフトウェア:
kubelet: Pod管理
kube-proxy: ネットワーク通信管理
コンテナランタイム: コンテナを実行する仕組み(例: Docker, containerd)

Pod

Kubernetesの最小単位。コンテナ(通常は1つ以上)とそのリソース(ネットワーク、ストレージ)をまとめる論理グループ
同じPod内のコンテナは、同一ネットワーク名前空間を共有
一般的には、1つのアプリケーションやマイクロサービスに対応

ReplicaSet

Podのレプリカを管理するコントローラー。指定した数のPodを常に維持します
Podが終了した場合、自動で再作成
スケール(Podの増減)を簡単に実現

Service

Podへのアクセスを提供するネットワークの抽象化
動的に変わるPodのIPアドレスを管理
外部や内部のリクエストをPodにルーティング

Deployment

アプリケーションのデプロイ、更新、スケーリングを管理するKubernetesリソース
ReplicaSetの管理: Podの数を指定し、その状態を維持
ロールアウトとロールバック: 新しいバージョンのアプリケーションを安全にデプロイ、必要に応じて以前の状態に戻す

control-plane

クラスタを管理するコンポーネント

etcd

分散KVS(キー・バリュー・ストア)
リソースの情報が保存される

kube-apiserver

リソースにアクセスするためのAPIサーバー
ユーザーや各コンポーネントからの操作はすべてkube-apiserverを経由する
etcdに保存された情報を用いる

kube-scheduler

作成されたPodをどのNodeに配置するかを決定する
配置には様々な条件式や設定が存在する

kube-controller-manager

リソースの状態を管理するコンポーネント
リソースの状態を監視し、あるべき状態になるように操作する

Nodes

kubelet

Node上のコンテナを管理する
スケジュールされたPodの作成や死活監視などを行う
コンテナランタイムのインタフェース(CRI)を通じて、
コンテナの操作を行う

kube-proxy

Podへの通信の設定を行うコンポーネント
Linuxのネットワーク機能を用いてパケットの転送を行う

Manifest

リソースの構成と設定を定義するための、 YAML または JSON 形式のファイル
これでコンテナ作成したりします
serviceやdevelopment毎にYAMLファイルを定義して、
実行させます

Discussion