kubernetesアーキテクチャまとめ
はじめに
記事で挙げているkubernetesアーキテクチャ(Master構成)は、k8sを利用する上で必ず必要という訳ではないですが、筆者はCKA(Certificate Kubernetes Administorator)資格をきっかけにk8sの仕組みを知り、k8sを使うことに対する怖さが全くなくなりました。
CKAに無事合格できたので、kubernetesアーキテクチャの概要をまとめてみました。
kubernetesアーキテクチャ概観
k8sはMasterとWorker Nodeの2つに分けることができます。Masterは、4つのコアコンポーネントで構成され、k8sの各種機能を実現しています。Worker Nodeは、主にpodをデプロイするために使用されるノードです。
API Server
API Serverは、多くの場合staticPodとしてkube-systemネームスペースに存在します。API Serverの役割は各コンポーネントとのやり取りで、HUBとして機能をします。クライアントとのkubectlコマンドも、API Serverが受け付けます。
API Server~クライアント
クライアントとAPI Serveの通信はTSLによって暗号化されています。この暗号化情報や、クライアントが接続するクラスター(API Server)の情報は、KubeConfigで設定します。
Scheduler
Schedulerは、多くの場合staticPodとしてkube-systemネームスペースに存在します。Schedulerの役割は、podを実行するノードを決定することです(デプロイはkubeletが行います)。kubernetesでは、pod実行ノードに制約をかけることのできる機能が多く存在します。
podが実行されるノードに対する制約
機能 | 説明 |
---|---|
taint | taintは、tolerationを持たないpodのデプロイを防ぎます |
affinity | affinityをpodに設定することで、特定のnodeにデプロイさせることができます |
drain | drainにより、特定のノードへのデプロイを防ぎます |
required resource | podデプロイ時にノードに要求するCPUやメモリを指定できます |
etcd
etcdは、Key-Valueベースのデータベースで、クラスター情報を管理します。etcdの実体は、多くの場合kube-systemネームスペースのDeploymentです。このetcdのスナップショットを取っておくことで、クラスターのリストアが可能です。このように、etcdはクラスターにとって最も大切なコンポーネントであり、単一障害点にならないように冗長化されることも多いです。
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb // etcdのsnapshotを取得
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot restore snapshotdb // etcdのrestoreが可能
※ etcdはAPI Serverと異なるTLSサーバ証明書を持つことが一般的です。
上記コマンド実行の際は、オプションでetcdのTLS証明書の指定が必要な場合が多いです。
controller manager
controller managerは、多くの場合staticPodとしてkube-systemネームスペースに存在し、各種kubernetesリソースのコントローラーの役割をします。例えば、controller managerに含まれるdeployment-controllerは、
「kubernetesリソースのdeploymentで定義されれているreplica数」と「実際にRunning状態の対象Pod数」を比較して、スケールイン/スケールアウトの司令をだします。controller managerが正常に動作していないと、「kubectl scaleコマンド実行したのに、pod数が変わらない」スケールされないなどの事象が起きます。
kubelet
kubeletは、各ノードのデーモンサービスとして動作します。
kubeletの主な役割は、
・API Serverの司令によるpodデプロイ
・ノード指定フォルダ配下のpodデプロイ(staticPodとしてデプロイされます)
・メトリクスをAPI Serverに送信
です。
kube proxy
kubeletは、daemonSetとしてkube-systemネームスペースに存在します(daemonSetは、任意のpodを各ノードに1つずつデプロイすることを可能にします)。kube proxyはトラフィック管理を行います。
Serviceの実体からみる、kube proxyの役割
kubernetesは、Dockerのオーケストレーションサービスです。つまり、kubernetesが行うのはDockerの"管理"で、全てのコンポーネントはDocker上で動作します。Kubernetesリソースは、Docker上でどのように存在しているのでしょうか??
例えば、Podであれば、Pod内の各コンテナはDockerコンテナとしてデプロイされます。Serviceはどうでしょうか?ServiceのようなDockerリソースは存在しません。Serviceの実体は、iptableのようなネットワーク設定です。kube proxyがkubernetesリソースであるServiceを検知して、Serviceをネットワーク設定に変換します。
kubectlデプロイまでの流れ
kubectlでPod作成コマンド実行~Podデプロイまでの一連の流れです。
以下、コマンド例です。
kubectl run --generator=run-pod/v1 hoge --image=nginx
kubectl → API Server
kubectlコマンドは、API Serverが受け付けます。
クライアントへのレスポンスは、2 のetcd更新後に返却します。API Server → etcd
API Serverは、etcdに作成するpod情報を記録します。
この時点で、podはPending状態になります。Scheduler → API Server
Schedulerは、etcdからデプロイされていないpodを検知し、
CPU・メモリ要求に応じてデプロイするノードを決定し、API Serverに教えます。API Server → kubelet
API Serverは、Schedulerが決定したノードのkubeletにpod作成要求を出し、
kubeletがPodデプロイをします。
デプロイ完了をすると、podはRunning状態になります。
Author And Source
この問題について(kubernetesアーキテクチャまとめ), 我々は、より多くの情報をここで見つけました https://qiita.com/cccggoo/items/1fccee0942e5196fc9a5著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .