K8s コンセプトの概要 - メモ

Kubernetes のマスターはクラスター制御ノードを指します。各 Kubernetes クラスターには、クラスター全体の管理と制御を担当するマスターが必要です。基本的に、Kubernetes のすべての制御コマンドはマスターに送信され、このプロセスでは、後で実行するすべてのコマンドは基本的にマスター上で実行されます。マスターは通常、クラスター全体の「本部」である独立したサーバー (高可用性展開には 3 台のサーバーが推奨されます) を占有しますが、マスターがダウンしたり使用できなくなったりすると、クラスター内のコンテナーアプリケーションの管理が効果がなくなります。。

1.1 次の主要なプロセスがマスター上で実行されています。

Kubernetes API Server (kube-apiserver) : HTTP Rest インターフェイスの主要なサービスプロセスを提供します。これは、
Kubernetes のすべてのリソースの追加、削除、変更、確認などの操作の唯一のエントリポイントです。また、Kubernetes のエントリプロセスでもあります。クラスター制御。
Kubernetes コントローラーマネージャー (kube-controller-manager) : Kubernetes のすべてのリソースオブジェクトの自動化されたコントロール
センターであり、リソースオブジェクトの「ジェネラルマネージャー」として理解できます。
Kubernetes スケジューラ (kube-scheduler) : リソースのスケジューリング (Pod スケジューリング) を担当するプロセス。
バス会社の「スケジューリングルーム」に相当します。
さらに、Kubernetes のすべてのリソースオブジェクトのデータは etcd に保存されるため、通常は etcd サービスをマスターにデプロイする必要があります。

2.ノードとは何ですか?

マスターと同様に、ノードは物理ホストまたは仮想マシンにすることができます。ノードは Kubernetes クラスター内のワークロードノードです。各ノードにはマスターによっていくつかのワークロード (Docker コンテナ) が割り当てられます。ノードがダウンすると、そのノード上のワークロードは他のノード上の
マスターに自動的に転送されます。

1.2 次の主要なプロセスが各ノードで実行されています。

Kubelet:ポッドに対応するコンテナの作成、起動、停止などのタスクを担当し、マスターと緊密に連携してクラスター管理の基本機能を実装します。

kube-proxy : Kubernetes Service の通信および負荷分散メカニズムを実装する重要なコンポーネント。

Docker エンジン (Docker): Docker エンジンは、ローカルコンテナーの作成と管理を担当します。

kubectl get nodes

3.ポッドとは何ですか?

ポッドは Kubernetes の最も重要な基本概念です

各ポッドには、「ルートコンテナ」と呼ばれる特別な一時停止コンテナがあります。Pause コンテナに対応するイメージは Kubernetes プラットフォームの一部であり、Pause コンテナに加えて、各ポッドには 1 つ以上の密接に関連するユーザービジネスコンテナも含まれています。

4. ラベルとは何ですか?

ラベルは、key=value のキーと値のペアであり、キーと
値はユーザーによって指定されます。ラベルは、ノード、ポッド、サービス、RC などのさまざまなリソースオブジェクトにアタッチできます。1 つのリソースオブジェクトで任意の数のラベルを定義でき、同じラベルを任意の数のリソースオブジェクトに追加することもできます。ラベルは通常、リソースオブジェクトの定義時に決定され、オブジェクトの作成後に動的に追加または削除することもできます。
1 つ以上の異なるラベルを指定したリソースオブジェクトにバンドルすることで、多次元のリソースグループ化管理機能を実装できるため、リソースの割り当て、スケジューリング、構成、展開、およびその他の管理タスクを柔軟かつ便利に実行できます。たとえば、さまざまなバージョンのアプリケーションをさまざまな環境に展開し、アプリケーションを監視および分析します (ログ記録、モニタリング、アラーム) など。一般的に使用されるラベルの例は次のとおりです。
バージョンタグ: "リリース":"安定版"、"リリース":"カナリア"。
環境タグ: "環境":"開発"、"環境":"QA"、"環境":"本番"。
スキーマタグ: "tier":"フロントエンド"、"tier":"バックエンド"、"tier":"ミドルウェア"。
パーティションラベル: "パーティション":"顧客 A"、"パーティション":"顧客 B"。
品質管理タグ: "track":"daily"、"track":"weekly"。
複数の Label Selector 式を組み合わせることで、複雑な条件選択を実現できます。複数の式は「,」で区切ることができます。
複数の条件の間には「AND」の関係があります。つまり、複数の条件が同時に満たされます。次の例:

name=redis-slave,env!=production
name notin (php-frontend),env!=production

myweb ポッドを例にとると、ラベルはそのメタデータで定義されています。

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web

管理オブジェクト RC および Service は、Selector フィールドを通じて Pod に関連付ける必要があるラベルを設定します。

apiVersion: v1
kind: ReplicationController
metadata:
    name: myweb
spec:
    replicas: 1
    selector:
        app: myweb
    template:
......
apiVersion: v1
kind: Service
metadata:
    name: myweb
spec:
    selector:
        app: myweb
ports:
- port: 8080

Deployment、ReplicaSet、DaemonSet、Job などの他の管理オブジェクトは、Selector のセットベースのフィルター条件を使用して定義できます。

例えば：

selector:
matchLables:
    app: web
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
- {key: environmetn, operator: NotIn, value: [dev]}

matchLabels は、ラベルのセットを定義するために使用されます。これには、Selector に直接書き込むのと同じ機能があります。matchExpressions は、セットベースのフィルター条件のセットを定義するために使用されます。使用可能な条件演算子には、In、NotIn、Exists、および DoesNotExist が含まれます。
matchLabels と matchExpressions が同時に設定されている場合、2 つの条件セットは AND 関係になります。つまり、セレクターのフィルター処理を完了するには、すべての条件が同時に満たされる必要があります。
Kubernetes での Label Selector の重要な使用シナリオは次のとおりです。

kube-controllerプロセスは、リソースオブジェクト RC で定義されたラベルセレクターを通じて監視対象の Pod コピーの数をフィルター処理するため、Pod のコピーの数は常に期待どおりに設定された完全自動制御プロセスに準拠します
。
kube-proxyプロセスは、サービスのラベルセレクターを通じて対応するポッドを選択し、
各サービスのリクエストを対応するポッドに転送するルーティングテーブルを自動的に構築することで、サービスのインテリジェントな負荷分散メカニズムを実現します。
特定のノードに特定のラベルを定義し、ポッド定義ファイルでラベルスケジューリング戦略 NodeSelector を使用することにより、kube-schedulerプロセスはポッド主導のスケジューリングの機能を実装できます。

5.レプリケーションコントローラー

RC は Kubernetes システムの中核概念の 1 つであり、簡単に言うと、実際に予想されるシナリオを定義します。つまり、特定の Pod のコピー数が常に特定の期待値を満たすことを宣言します。 RC には以下のいくつかの部分が含まれます。
Pod が期待するコピー数は、
ターゲット Pod の Label Selector をフィルタリングするために使用され、
Pod のコピー数が期待数よりも少ない場合は、新しい Pod の Pod テンプレート (テンプレート) を作成するために使用されます。。

以下は、完全な RC 定義の例です。これにより、tier=frontend ラベルを持つ Pod (Tomcat コンテナーを実行している) が、
Kubernetes クラスター全体で常に 1 つのコピーのみを持つことが保証されます。

apiVersion: v1
kind: ReplicationController
metadata:
    name: frontend
spec:
    replicas: 1
    selector:
        tier: frontend
    template:
        metadata:
        labels:
            app: app-demo
            tier: frontend
        spec:
            containers:
        - name: tomcat-demo
            image: tomcat
            imagePullPolicy: IfNotPresent
            env:
            - name: GET_HOSTS_FROM
                value: dns
            ports:
            - containerPort: 80

6.展開

RC と比較した Deployment の最大のアップグレードの 1 つは、現在のポッドの「デプロイメント」の進行状況をいつでも確認できることです。実際、ノードの作成、スケジュール設定、バインド、およびポッドのターゲットノードでの対応するコンテナの開始という完全なプロセスには一定の時間がかかるため、システムは N ポッドコピーのターゲット状態を開始すると予想されます。これは、継続的に変化する「展開プロセス」の結果として得られる最終状態です。

6.1 導入の一般的なシナリオ:

Deployment オブジェクトを作成して、対応するレプリカセットを生成し、ポッドレプリカの作成を完了します。

Deploymentのステータスを確認して、デプロイが完了したか(Podのコピー数が期待値に達したか)を確認します。

デプロイメントを更新して新しいポッドを作成します (イメージのアップグレードなど)。
現在のデプロイメントが不安定な場合は、以前のデプロイメントバージョンにロールバックし、
デプロイメントを一時停止して複数の PodTemplateSpec 構成項目を一度に変更してから、デプロイメントを再開して続行します。高負荷を処理するために新しいリリースのデプロイメントを展開します。
リリースが成功したかどうかを示す指標としてデプロイメントのステータスを表示します。
不要になった古いバージョンの ReplicaSet をクリーンアップします。

次の内容を含む tomcat-deployment.yaml という名前のデプロイメント記述ファイルを作成します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: frontend
spec:
    replicas: 1
    selector:
        matchLabels:
            tier: frontend
    matchExpressions:
        - {key: tier, operator: In, values: [frontend]}
template:
    metadata:
        labels:
            app: app-demo
            tier: frontend
    spec:
       containers:
       - name: tomcat-demo
         image: tomcat
         imagePullPolicy: IfNotPresent
         ports:
         - containerPort: 8080

上記の出力に含まれる量は次のように説明されます。

$ kubectl get deployments

DESIRED : ポッドレプリカ数の期待値、つまり、Deployment で定義されたレプリカ
CURRENT : 現在のレプリカ値は、実際には、Deployment によって作成されたレプリカセット内のレプリカ値です。この値は、DESIRED に達する
まで。デプロイメント・プロセス全体が完了したことを示します
UP-TO-DATE : 最新バージョンの Pod のコピー数で、ローリング・アップグレード・プロセス中に正常にアップグレードされた Pod コピーの数を示すために使用されます。 AVAILABLE: で使用可能な Pod コピーの
数現在のクラスター (クラスター内) 現在存続しているポッドの数
次のコマンドを実行して、対応するレプリカセットを表示します。その名前がデプロイメントの名前に関連していることがわかります。

kubectl get rs

7.水平ポッドオートスケーラーTODO

水平ポッド自動スケーリング (ポッド水平自動拡張、HPA)

HPA は、以前の RC およびデプロイメントと同様に、Kubernetes リソースオブジェクトです。
これは、指定された RC によって制御されるすべてのターゲット Pod の負荷変化を追跡および分析して、ターゲット Pod のコピー数を目標を絞った方法で調整する必要があるかどうかを判断する HPA の実装原理です。現在、HPA には
次の 2 つの方法で Pod 負荷を測定できます。

CPU使用率パーセンテージ

サービスの 1 秒あたりの対応するリクエスト数 (TPS または QPS) など、アプリケーションによってカスタマイズされたメトリクス

CPUUtilizationPercentage は算術平均、つまりターゲットポッドのすべてのコピーの平均 CPU 使用率です。ポッド自体の
CPU 使用率は、ポッドの現在の CPU 使用率をそのポッドリクエストの値で割ったものです。たとえば、ポッドのポッドリクエストを 0.4 として定義し、現在のポッドの CPU 使用率が 0.2 である場合、その CPU 使用率は 50% になります
。このようにして、
RC によって制御されるすべての Pod コピーの CPU 使用率の算術平均を計算できます。CPUUtilizationPercentage の値が特定の時点で 80% を超えた場合、現在の Pod コピー数では
後続のリクエストをサポートするには不十分である可能性が高く、動的拡張が必要であることを意味します。ピークリクエスト期間が経過すると、Pod の CPU使用率が低下し、
対応する Pod コピーの数が適切なレベルまで自動的に削減されるはずです。ターゲット Pod が Pod Request 値を定義していない場合、CPUUtilizationPercentage を使用して
Pod を水平方向に自動的に拡張することはできません。CPUUtilizationPercentage の使用に加えて、Kubernetes はバージョン 1.2
からアプリケーションでカスタマイズされたメトリクスもサポートしようとしています。

HPA 定義の具体的な例を次に示します。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
    name: php-apache
    namespace: default
spec:
    maxReplicas: 10
    minReplicas: 1
    scaleTargetRef:
        kind: Deployment
        name: php-apache
    targetCPUUtilizationPercentage: 90

上記の定義によれば、この HPA コントロールのターゲットオブジェクトは
php-apache という名前の Deployment 内の Pod コピーPod コピーの CPUUtilizationPercentage の値が 90% を超えると、自動動的拡張がトリガーされます。、
拡張または縮小するときに満たさなければならない制約は、Pod レプリカの数が 1 ～ 10 であることです。
さらに、YAML ファイルを直接定義して kubectrl create コマンドを呼び出すことによって、HPA リソースオブジェクトを作成できます。また、
次の簡単なコマンドラインを使用して、同等の HPA オブジェクトを直接作成することもできます。

$ kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10

8.ステートフルセット

Kubernetes システムでは、ポッド管理オブジェクト RC、Deployment、DaemonSet、および Job はすべてステートレスサービスを対象としています。しかし実際には
、多くのサービス、特に MySQL クラスター、MongoDB クラスター、Kafka クラスター、
ZooKeeper クラスターなどの一部の複雑なミドルウェアクラスターはステートフルです。これらのアプリケーションクラスターには 4 つの共通点があります:
各ノードには固定の ID ID があります。この ID を使用すると、クラスター内のメンバーが相互に検出して通信できるようになります。
クラスターの規模は比較的固定されており、自由に変更することはできません。クラスター
内の各ノードはステートフルであり、通常、データは永続的に保持されます。ストレージ内に
ディスクが損傷した場合は、が発生すると、クラスタ内のノードが正常に動作できなくなり、クラスタ機能が損傷します。

StatefulSet特性

StatefulSet 内の各ポッドには、安定した一意のネットワーク識別子があり、クラスター内の他のメンバーを検出するために使用できます。StatefulSetの名前を
kafkaとすると、1番目のPodはkafka-0、2番目のPodはkafka-1というように、
StatefulSetで制御されるPodコピーの開始・停止シーケンスが制御されます。ポッド、最初の n-1 ポッドはすでに実行されており、準備ができています。StatefulSet
のポッドは、PV または PVC を通じて実装される安定した永続ストレージボリュームを使用します。ポッドが削除されても、
StatefulSet に関連するストレージボリュームは削除されませんデフォルト (データセキュリティの確保のため)

StatefulSet は、ポッドの状態データを保存するために PV ボリュームにバンドルされているだけでなく、ヘッドレスサービスでも使用する必要があります。つまり、各 StatefulSet 定義で、どのヘッドレスサービスに属するかを宣言する必要があります。ヘッドレスサービスと通常のサービスの主な違いは、クラスター IP がないことです。ヘッドレスサービスの DNS ドメイン名が解析されると、サービスに対応するすべてのポッドのエンドポイントリストが返されます。
ヘッドレスサービスに基づいて、StatefulSet は、StatefulSet によって制御される各 Pod インスタンスの DNS ドメイン名を作成します。
このドメイン名の形式は次のとおりです。

$(ポッド名).$(ヘッドレスサービス名)

たとえば、3 ノードの Kafka StatefulSet クラスターに対応するヘッドレスサービスの名前は kafka で、StatefulSet の名前は kafka である場合、StatefulSet 内の 3 つの Pod の DNS 名は kafka-0.kafka、kafka- となります
。 1.kafka、kafka-3.kafka、これらの DNS 名は
クラスター構成ファイルで直接修正できます。

9.サービス

Service は Kubernetes のコアリソースオブジェクトの 1 つでもあります。Kubernetes の各 Service は、実際にはよく言及されるマイクロサービスアーキテクチャにおけるマイクロサービスです。Pod や RC などのリソースオブジェクトに関する前述の説明は、実際には Kubernetes Service を説明するためのものです。

サービスは、サービスのアクセス入口アドレスを定義します。フロントエンドアプリケーション (Pod) は、この入口を使用して、その背後にあるポッドレプリカで構成されるクラスターインスタンスのグループにアクセスします。サービスとそのバックエンドポッドレプリカクラスター間の接続は、次の方法で実現されます。ラベルセレクター。縫い合わせたバットジョイント。RC の役割は、実際には、サービスのサービス機能とサービス品質が常に期待される基準を満たしていることを確認することです。

9.1 サービスにアクセスする外部システムの問題

Kubernetes の 3 種類の IP

ノード IP: ノードの IP アドレス
ポッド IP: ポッドの IP アドレス
クラスター IP: サービスの IP アドレス

ノード IP は、Kubernetes クラスター内の各ノードの物理ネットワークカードの IP アドレスです。これは実際の物理ネットワークです。このネットワークに属するすべてのサーバーは、接続されていないノードがあるかどうかに関係なく、このネットワークを通じて直接通信できます。この Kubernetes クラスター。これは、Kubernetes クラスターの外部のノードが Kubernetes クラスター内のノードまたは TCP/IP サービスにアクセスする場合、ノード IP を介して通信する必要があることも示しています。

ポッド IP は、各ポッドの IP アドレスです。これは、docker0 ブリッジの IP アドレスセグメントに基づいて、Docker エンジンによって割り当てられます。これは、通常、仮想の第 2 層ネットワークです。前述したように、Kubernetes では、異なるノード上にノードが配置されている必要があります。相互に直接通信できるため、Kubernetes 内の 1 つのポッド内のコンテナが別のポッドのコンテナにアクセスする場合、ポッド IP が配置されている仮想第 2 層ネットワークを介して通信し、実際の TCP/IP トラフィックは、ノード IP が配置されている物理ネットワークカード。

サービスのクラスター IPも仮想 IP ですが、どちらかというと「偽」の IP ネットワークに似ています。その理由は次のとおりです。
クラスター IP は Kubernetes Service オブジェクト上でのみ機能し、Kubernetes によって IP アドレスが管理および割り当てられます。クラスター IP アドレスプールから供給されます) 応答する「エンティティネットワークオブジェクト」がないため、クラスター IP を ping できません。クラスター IP は
サービスポートと組み合わせて特定の通信ポートを形成することのみ可能です。別のクラスター IP には TCP / IP 通信であり、それらは Kubernetes クラスターなどの閉じられた空間に属しています。クラスター外のノードがこの通信ポートにアクセスしたい場合は、追加の作業を行う必要があります。Kubernetes クラスター内では、ノード IP ネットワーク、ポッド IP 間の通信ネットワークとクラスター IP ネットワークは、Kubernetes 自体によって設計された特別なルーティングルールを採用しています。これは、私たちがよく知っている IP ルーティングとは大きく異なります。

上記の分析と要約に基づいて、基本的に、サービスのクラスター IP は Kubernetes クラスター内のアドレスに属しており、
このアドレスはクラスター外では直接使用できないことがわかります。実際、私たちが開発するビジネスシステムでは、一部のサービスを
Kubernetes クラスターの外部のアプリケーションまたはユーザーに提供する必要があります。典型的な例は、上記の tomcat-service のような Web 側のサービスモジュールです。、ユーザーはどのようにアクセスしますか? NodePort の使用は、上記の問題を解決する最も直接的かつ効果的な一般的な方法です。tomcat-service を例として、Service の定義で次の拡張を行うだけです
(コードの太字部分を参照)。

このうち、属性 nodePort:31002 は、tomcat-service の NodePort が手動で 31002 に指定されていることを示します。それ以外の場合は、Kubernetes が使用可能なポートを自動的に割り当てます。次に、ブラウザで http://:31002/ にアクセスすると、Tomcat のウェルカムインターフェイスが表示されます。NodePort の実装では、外部アクセスを必要とするサービスのために、Kubernetes クラスター内の各ノードでポートを開きます。対応する TCP リスニング用ポートの場合、外部システムは任意のノードの IP アドレスと特定の NodePort ポート番号を使用してこのサービスにアクセスできます。任意のノードで netstat コマンドを実行すると、NodePort が監視されていることを確認できます。

ただし、NodePort は、負荷分散の問題など、サービスへの外部アクセスに関するすべての問題を完全に解決したわけではありません。クラスター内に 10 個のノードがある場合、現時点ではロードバランサーを使用するのが最善です。外部リクエストはこのロードバランサーの IP アドレスにアクセスするだけでよく、ロードバランサーはトラフィックを後続のノードに転送する役割を果たします。、図 1.15 に示すように

図 1.15 のロードバランサーコンポーネントは Kubernetes クラスターから独立しており、通常はハードウェアロードバランサーであるか、HAProxy や Nginx などのソフトウェアで実装されます。通常、サービスごとに、トラフィックをバックエンドノードに転送するように対応するロードバランサーインスタンスを構成する必要がありますが、これによりワークロードとエラーの可能性が増加します。Kubernetes は自動化されたソリューションを提供します。クラスターが Google のパブリッククラウド GCE 上で実行されている場合、サービスの type=NodePort が type=LoadBalancer に変更されている限り、Kubernetes は対応するロードバランサーインスタンスを自動的に作成し、その IP アドレスを返します。外部クライアントが使用するため。他のパブリッククラウドプロバイダーも、この機能をサポートするドライバーを実装している限り、上記の目標を達成できます。さらに、ベアメタル上の同様のメカニズム (Bare Metal Service Load Balancer) も開発されています。

10.仕事

バッチ処理タスク Job は RC、Deployment、ReplicaSet、DaemonSet に似ており、Pod コンテナのグループも制御します。この観点から見ると、ジョブは Pod コピーの特別な自動制御でもありますが、同時に、Pod コピーを制御するジョブの動作メカニズムは RC などのコントローラーの動作メカニズムとは異なります。

(1) ジョブによって制御される Pod コピーは一時的に実行され、それぞれが 1 回だけ実行される一連の Docker コンテナーとみなすことができます
。ジョブによって制御されるすべての Pod コピーの実行が終了すると、対応するジョブも終了します。Job は RC などのレプリカコントローラーとは実装が異なります
。Job によって生成された Pod レプリカは自動的に再起動できません。対応する Pod レプリカの RestartPoliy は Never に設定されます。したがって、対応する Pod のコピーが実行されると、対応する Job は制御ミッションを完了します。つまり、Job によって生成された Pod は Kubernetes 内に一時的に存在します。Kubernetes は、バージョン 1.5 以降、crontab に似たスケジュールされたタスクである CronJob を提供しています。これは、一定の間隔で繰り返し実行する必要がある特定のバッチ処理タスクの問題を解決します。

(2) ジョブによって制御される Pod コピーの動作モードにより、複数のインスタンスを並行して計算できます。TensorFlow フレームワークを例に取ると、機械学習コンピューティングタスクを 10 台のマシンに分散して各マシンで実行できます。ワーカーはコンピューティングタスクを実行します。これは、ジョブを通じて 10 個の Pod コピーを生成し、同時にコンピューティングを開始するのに非常に適しています。

11.ボリュームストレージボリューム

ボリューム (ストレージボリューム) は、複数のコンテナからアクセスできる Pod 内の共有ディレクトリです。Kubernetes のボリュームの概念、使用法、目的は Docker のボリュームと似ていますが、この 2 つは同等ではありません。まず、Kubernetes のボリュームはポッド上で定義され、ポッド内の複数のコンテナによって特定のファイルディレクトリにマウントされます。次に、Kubernetes のボリュームはポッドと同じライフサイクルを持ちますが、ポッドのライフサイクルとは異なります。コンテナのライフサイクルは関係なく、コンテナが終了または再起動されても、ボリューム内のデータは失われません。最後に、Kubernetes は、GlusterFS、Ceph、その他の高度な分散ファイルシステムなど、複数のタイプのボリュームをサポートします。

ポッド上でボリュームを宣言し、コンテナ内のボリュームを参照して、コンテナ内のディレクトリにマウントします。たとえば、datavol という名前のボリュームを以前の Tomcat ポッドに追加し、それをコンテナの /mydata-data ディレクトリにマウントしたい場合、ポッド定義ファイルに次の変更を加えるだけで済みます (太字のコードに注意してください) ) の部分:

12. 永続ボリューム

前述のボリュームは Pod 上に定義され、コンピューティングリソースの一部ですが、実際には、ネットワークストレージはコンピューティングリソースとは比較的独立して存在するエンティティリソースです。たとえば、仮想マシンを使用する場合、通常は最初にネットワークストレージを定義し、次にそこから「ネットワークディスク」を作成して仮想マシンに接続します。Persistent Volume (PV) とそれに関連する Persistent Volume Claim (PVC) も同様の役割を果たします。

PV は、Kubernetes クラスター内の特定のネットワークストレージに対応するストレージとして理解でき、ボリュームに似ていますが、次のような違いがあります。
PV はネットワークストレージとしてのみ使用でき、どのノードにも属しませんが、各ノードからアクセスできます。
PV は Pod 上では定義されませんが、Pod とは独立して定義されます。

現在 PV でサポートされているタイプには、gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC (FibreChannel)、
Flocker、NFS、iSCSI、RBD (Rados Block Device)、CephFS、Cinder、GlusterFS、Vsphere Volume、Quobyte Volumes、VMware Photon、Portworx Volumes が含まれます。、ScaleIO ボリュームと HostPath (スタンドアロンテストのみ)

以下は、NFS タイプ PV の YAML 定義ファイルで、5Gi の記憶域スペースが必要であることを宣言しています。

さらに重要なのは PV の accessModes 属性で、現在次のタイプがあります。
◎ ReadWriteOnce:読み取りおよび書き込み権限。単一のノードによってのみマウントできます。
◎ ReadOnlyMany:読み取り専用権限。複数のノードによるマウントを許可します。
◎ ReadWriteMany:読み取りおよび書き込み権限。複数のノードによるマウントが可能です。

Pod が特定のタイプの PV を適用したい場合は、まず PersistentVolumeClaim オブジェクトを定義する必要があります

次に、ポッドのボリューム定義で上記の PVC を参照するだけです。

最後にPVの状況についてお話します。PV はステートフルオブジェクトであり、その状態には次のものが含まれます。
◎使用可能: アイドル状態。
◎バインド済み: すでに特定の PVC にバインドされています。
◎解放済み: 該当する PVC は削除されましたが、クラスタによってリソースが回復されていません。
◎失敗： PV 自動リサイクルに失敗しました。

13.名前空間

名前空間は Kubernetes システムにおいて非常に重要な概念であり、多くの場合、名前空間はマルチテナントのリソース分離を実現するために使用されます。ネームスペースは、クラスター内のリソースオブジェクトをさまざまなネームスペースに「割り当て」て、論理的にグループ化されたさまざまなプロジェクト、小さなグループ、またはユーザーグループを形成します。これにより、さまざまなグループがクラスター全体のリソースを共有して使用できると同時に、管理も可能になります。別々に。

Kubernetes クラスターが開始されると、default という名前の名前空間が作成され、kubectl を通じて表示できます。

14.注釈

アノテーションはラベルに似ており、これもキーと値のペアの形式で定義されます。違いは、Label には厳密な命名規則があり、Kubernetes オブジェクトのメタデータを定義し、Label Selector に使用されることです。アノテーションとは、外部ツールによる検索を容易にするために、ユーザーが任意に定義した付加情報です。多くの場合、Kubernetes モジュール自体が Annotation を通じてリソースオブジェクトの特別な情報をマークします。一般的に、Annotation を使用して記録される情報は次のとおりです: タイムスタンプ、リリースなどのビルド情報、リリース情報、Docker イメージ情報
などID番号、PR番号、イメージハッシュ値、Dockerレジストリアドレスなどのログライブラリ、監視ライブラリ、解析ライブラリなどのリソースライブラリのアドレス情報ツール名、バージョン番号、プログラムデバッグツール情報等チームの電話番号、担当者名、URL等の連絡先情報

15.構成マップ

Kubernetes ConfigMap の機能と価値を正確かつ深く理解するには、Docker から始める必要があります。
Docker
が、プログラム、依存ライブラリ、データ、構成ファイルを変更されていないイメージファイルに「パッケージ化して固定」することで、アプリケーションのデプロイメントの問題を解決することはわかっていますが、これによっても困難が生じます。問題は、構成ファイルのパラメータを変更する際にどのように変更するかです。ランタイム。Docker コンテナの起動後にコンテナ
内の構成ファイルを変更し、新しい構成ファイルを使用してコンテナ内のユーザーのメインプロセスを再起動することは不可能です。この問題を解決するために、Docker は 2 つの方法を提供します。
実行時にコンテナーの環境変数を介してパラメーターを渡す方法と、
Docker Volume を介してコンテナー外の構成ファイルをコンテナーにマッピングする方法です。

どちらの方法にも長所と短所がありますが、ほとんどのアプリケーションは通常 1 つ以上の構成ファイルからパラメータを読み取るため、ほとんどの場合、後者の方法の方がシステムに適しています。ただし、この方法には明らかな欠陥もあります。コンテナにマッピングする前に、ターゲットホスト上に対応する構成ファイルを作成する必要があります。

k8s デザイン:

まず、すべての構成項目をキーと値の文字列として扱います。もちろん、値はテキストファイルから取得することもできます。たとえば、構成項目のパスワード =123456、ユーザー = root、およびホスト = 192.168.8.4 は、接続を表すために使用され
ます. FTP サーバーの構成パラメーター。これらの構成アイテムは、Map テーブルのアイテムとして使用できます。Map データ全体を Kubernetes の Etcd データベースに永続的に保存でき、Kubernetes 関連コンポーネントまたは顧客アプリケーションが CRUD を使用してこれらのデータを操作できるようにするための API が提供されます。構成パラメーターを保存するために使用される上記の専用のマップは、Kubernetes ConfigMap リソースオブジェクトです。

Kubernetes は、etcd に保存されている ConfigMapをボリュームマッピングを通じてターゲットポッドのさらに、
ConfigMap 内の Key-Value データが変更された場合、Pod にマッピングされている「設定ファイル」もそれに応じて自動的に更新されます。その結果、Kubernetes ConfigMap は
分散システムで最もシンプルな構成センター (使い方は簡単ですが、その背後にある実装はより複雑です) になり、対応するアプリケーションに侵入しません。