クラスターリソース管理


異種の異なる構成のホストを管理するために、ポッドの運用と保守管理を容易にするために、Kubernetesは多くのクラスタ管理構成と管理機能を提供します。名前空間で分割されたスペースは、ノードノードのラベルと汚染を作成することにより、ポッドのスケジューリングに使用されます待って

ノード

ノードはkubernetesクラスターの作業ノードであり、物理マシンまたは仮想マシンにすることができます。

ノードのステータス
ノードには、次のステータス情報が含まれています

  • アドレス
    HostName:kubeletの--hostname-overrideパラメーターで置き換えることができます。
    ExternalIP:クラスターの外部にルーティングできるIPアドレス。
    InternalIP:クラスターの内部で使用されるIP。クラスターの外部からはアクセスできません。
  • 条件
    OutOfDisk:Trueディスク容量が少ないときに
    準備完了:ノードコントローラーはノードのステータスレポートを40秒以内に不明として受信しておらず、正常性はTrue、それ以外はFalseです。
    MemoryPressure:ノードにメモリプレッシャーがない場合はTrue、それ以外の場合はFalse。
    DiskPressure:ノードにディスクプレッシャーがない場合はTrue、それ以外の場合はFalse。
  • 容量
    CPU
    メモリ
    実行できる
    ポッドの最大数情報:OS、kubernetes、dockerなど、ノードの一部のバージョン情報。

ノード管理

このノードで
kubectl Cordon へのポッドスケジューリングを無効にします
このノードのすべてのポッド
kubectlドレイン追放し ます

このコマンドは、このノード(DaemonSetを除く)のすべてのポッドを削除し、他のノードで再起動します。通常、この
コマンドは、ノードのメンテナンスが必要な場合に使用されますこのコマンドを直接使用すると、kubectl cordonが自動的に呼び出されます コマンド。ノードのメンテナンスが完了してkubeletが起動したら、kubectl uncordonを使用します ノードをkubernetesクラスターに追加できます。

名前空間

名前空間を使用して、Kubernetesクラスタに複数の「仮想クラスタ」を作成できます。これらの名前空間は完全に分離することも、1つの名前空間のサービスが他の名前空間のサービスにアクセスできるようにするメソッドを使用することもできます。 CentOSにkubernetes1.6クラスターをデプロイしたとき、名前空間にまたがる適切なサービスを使用しました。たとえば、Traefikイングレスとkube-system名前空間の下のサービスは、クラスター全体にサービスを提供できます。これらはRBACを通じて定義する必要があります。達成する色のレベル


名前空間は一意の名前空間を提供できるため、複数の名前空間を使用するのが適切な場合、部分的な環境分離を実現できます。プロジェクトとスタッフが多い場合、本番環境、テスト、開発などのプロジェクト属性に基づいて、さまざまな名前空間を検討できます

名前空間の使用

クラスター
どの名前空間kubectlがnsを取得するかを取得します。

デフォルトでは、クラスターには2つの名前空間、defaultとkube-systemがあります。
-nを使用して、kubectlコマンドを実行するときの操作の名前空間を指定できます。
ユーザーの一般的なアプリケーションのデフォルトはデフォルトであり、クラスター全体にサービスを提供するクラスター管理に関連するアプリケーションは、通常
、kubernetesクラスターのインストール時にデプロイするkubedns、heapseter、EFKなどのkube -systemの名前空間の下にデプロイされます。この名前空間の下で待機しています。さらに、すべてのリソースオブジェクトが名前空間に対応するわけではなく、nodeとpersistentVolumeはどの名前空間にも属しません。

ラベル

ラベルは、オブジェクト(ポッドなど)に関連付けられたキーと値のペアです。オブジェクトの作成時、またはオブジェクトの作成後いつでも指定できます。Labelsの値はシステム自体には意味がなく、ユーザーにのみ意味があります。

ラベルを使用すると、組織構造をシステムアーキテクチャ(コンウェイの法則など)にマッピングできるため、マイクロサービスの管理が容易になります。オブジェクトには、次のタイプのラベルを付けることができます

"release": "stable"、 "release": "canary"
"environment": "dev"、 "environment": "qa"、 "environment": "production"
"tier": "frontend"、 "tier": "backend"、 "tier": "cache"
"partition": "customerA"、 "partition": "customerB"
"track": "daily"、 "track": "weekly"
"team": "teamA"、 " team: ":" teamB "

文法と文字セット

ラベルキーの構成:

  • 63文字
  • 接頭辞を使用するか、/を使用します。接頭辞はDNSサブドメインである必要があり、253文字を超えることはできません。システム内の自動コンポーネントによって作成されるラベルは、
    接頭辞を指定する必要があります。kubernetes.io/はkubernetesによって予約されています
  • 開始点は、文字⺟(任意のタイプを記述できます)または数字で、中央にハイフン、アンダースコア、ドットを含める必要があります

ラベル値の構成:

  • 63文字
  • 開始点は、文字⺟(任意のタイプを記述できます)または数字で、中央にハイフン、アンダースコア、ドットを含める必要があります

ラベルセレクター

ラベルは一意ではありません。多くのオブジェクトが同じラベルを持つ可能性があります。
ラベルセレクターを介して、クライアント/ユーザーはオブジェクトコレクションを指定し、ラベルセレクターを介してオブジェクトコレクションを操作できます。

ラベルセレクタには2つのタイプがあります。

  • 等価ベース:=、== 、! =演算子を使用でき、カンマを使用して複数の式を区切ることができます
  • セット・ベース:!演算子、notin、中に使用することができ、オペレータは、直接キーラベルを書き込むことができない、フィルターを示すことがある
    にかかわらず、値が何であるかを値のキーオブジェクト⽽の鍵を!ラベルのないオブジェクト

$ kubectl get pods -l environment = production、tier = frontend
$ kubectl get pods -l 'environment in(production)、tier in(frontend)'
$ kubectl get pods -l 'environment in(production、qa)'
$ kubectl get pods -l 'environment、environment notin(frontend)'

APIオブジェクトにラベルセレクターを設定する

在 service 、 replicationcontroller 等object中有对pod的label selector,使⽤⽅法只能使⽤等于操作,例如:
selector:
   component: redis
   
在 Job 、 Deployment 、 ReplicaSet 和 DaemonSet 这些object中,⽀持set-based的过滤,例如
selector:
   matchLabels:
      component: redis
   matchExpressions:
     - {key: tier, operator: In, values: [cache]}
     - {key: environment, operator: NotIn, values: [dev]}   
注釈

注釈。アノテーションは、Kubernetesリソースオブジェクトを任意の非識別メタデータに関連付けることができます。これらのメタデータは、クライアント(ツールやライブラリなど)を使用して取得できます。

LabelとAnnotationはどちらもメタデータをKubernetesリソースオブジェクトに関連付けることができます。ラベルは主にオブジェクトを選択するために使用され、特定の条件を満たすオブジェクトを選択できます。対照的に、注釈を使用してオブジェクトを識別および選択することはできません。アノテーションのメタデータは多かれ少なかれ、構造化されているか、構造化されていないか、またはラベルで許可されていない文字を含むことができます。

注釈とラベルはどちらもキー/値のキーと値のマッピング構造です:
"annotations":{
"key1": "value1"、
"key2": "value2"
}

アノテーションに記録できるオブジェクト情報

  • 構成層によって管理されるフィールドを宣言します。注釈を使用してそのようなフィールドを関連付けると、次の構成ソースを区別できます。クライアントまたはサーバーによって設定されたデフォルト値、自動生成フィールド、または自動生成された自動スケーリングおよび自動サイズ設定システム構成フィールド。
  • 情報、バージョン情報、またはミラー情報を作成します。たとえば、タイムスタンプ、バージョン番号、gitブランチ、PRシリアル番号、イメージハッシュ値、倉庫の住所などです。
  • ログを記録し、ストレージウェアハウスを監視、分析、または監査するためのポインター
  • 名前、バージョン、作成情報などのクライアント(ライブラリまたはツール)情報のデバッグに使用できます。
  • ユーザー情報と、Kubernetes状態の関連オブジェクトのURL情報などのツールまたはシステムソース情報。
  • 構成やチェックポイントなどの軽量展開ツールのメタデータ。
  • 担当者の電話または連絡方法、またはチームサイトなどの関連情報が記載されている情報のリスト。



おすすめ

転載: www.cnblogs.com/g2thend/p/12745145.html