コンポーネントの原理

7985 ワード

テキストリンク

クバーネディスコンポーネント

Control Plane / Master node

etcd=データベース

api-server=ユーザー認証、管理を含む

の包括的な管理

コントローラ=複数種類のコントローラ

scheduler

Worker node

kubelet=登録ノード、モニタノード、podなど

kube-proxy

クバーネディスシステムコンポーネントはapi-serverとのみ通信する

kube-apiserver

アプリケーションプログラミングインターフェース(API)とは
コンピュータ・プログラム間の相互作用と情報交換を促進するためのデータと機能のセットを提供します.

kube-apiserver = REST API Server

kube-apiserverは、ユーザー認証、管理を含むクラスタ全体に要求を送信する

を担当する重要な役割を果たしています(etcdに格納されています).

kube-apiserverは一般的なREST APIサーバであり、通常kubectl CLIツールを使用してクラスタにリクエストを送信します.
ko.wikipedia.org/wiki/REST

APIサーバの動作

クライアント認証-認証プラグイン
-APIサーバは、1つ以上のプラグインによってクライアント認証を実行します.
-HTTPリクエストを確認して実行-認証方法に従って証明書またはHTTPヘッダから情報を収集
-プラグインはクライアントのユーザー情報を抽出し、承認フェーズでこれらのデータを使用します.

クライアントまたは承認プラグイン
-APIサーバは、要求されたタスクが要求されたリソースに対して実行できるかどうかを決定する

要求されたリソースの確認と変更-コントローラプラグインの追加
-リソースの作成、変更、削除時にAdd Controllerに要求を送信します.
-欠落したフィールドを初期値に設定するか、初期値に再定義します.

リソースの検証と保存
-APIサーバは、検証対象の有効性→etcdに保存→クライアントに応答を返す

APIサーバの呼び出し

$ kubectl cluster-info
Kubernetes control plane is running at https://10.178.0.41:26443

$ curl https://10.178.0.41:26443
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

認証と承認

# kubeconfig 파일로부터 CA 인증서 추출
kubectl config view --minify --raw --output 'jsonpath={..cluster.certificate-authority-data}' | base64 -d > k8s-ca.cert

# --cacert 옵션으로 사용자가 명시적으로 CA 인증서 제공
curl --cacert k8s-ca.cert https://<IP>:<Port>

# JWT 토큰 추출
TOKEN=$(kubectl get secret $(kubectl get sa default -ojsonpath="{.secrets[0].name}") -ojsonpath="{.data.token}" | base64 -d)

# 권한 부여
kubectl create clusterrolebinding default-cluster-admin --clusterrole cluster-admin --serviceaccount default:default

# JWT 토큰을 헤더로 넣어서 사용자 인증
curl -k -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>

Handle

# Node list
curl -v -k -X GET -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/nodes

# Pod list
curl -v -k -X GET -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/namespaces/default/pods

# Pod delete
curl -v -k -X DELETE -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/namespaces/default/pods/mynginx

# API에 대한 curl 호출 방법 출력
kubectl get service -v 9

etcd (HA Cluster)

etcdは、api-serverとのみ通信するkey-value形式で分散されたデータ・リポジトリです.

Cluster & HA Cluster

KubernetesはMaster Nodeと複数のWorker Nodeからなる

1つのプライマリノード

のみが使用されている場合、プライマリノードのVMに障害が発生すると、クラスタは

にダウングレードされます.
したがって、

は、HAクラスタからなる複数のMaster Nodeを配備する

である.

HAクラスタは、プライマリノードのInstanceを各プライマリノードに配備する

Options for HA topology

Stacked etcd topology

This topology couples the control planes and etcd members on the same nodes

1ノードのダウンロードには2つのetcdがあり、定格数に合致せず、高可用性の問題がありますか?

External etcd topology

クラスタとetcd分離モデル

ノードDownはHAに与える影響は小さいが、2倍のインスタンス

が必要である.
欠点:ThisトポロジはHAトポロジをスタックするホスト数の2倍を必要とする.etcdクラスタ(一貫性)

etcdをクラスタとして構築するには、etcdインスタンス間の通信に必要なポートを開く必要があります.(クラスタ内部通信用)

配備の安全を確保するため、etcdインスタンス間の通信はSSL承認

を通過する.

RAFTプロトコルのアルゴリズムを使用
ko.wikipedia.org/wiki/raft(コンピュータ科学)

※etcdを持つノードは7個を超えてはいけません.(CSP規格5 Xを超える)

kube-proxy

エージェントの典型的な役割は、接続によってクライアントとサーバのトラフィックをクライアントに渡すことです.
kube-proxy : process that runs on each node in the kubernetes cluster to look for new services and every time a new service is created, it creates the appropriate rules on each node to forward traffic to those services to the backend pods