宣言型API
私は、私はそれがどんなものか状態を期待する「宣言」に明確に定義されたAPIオブジェクトを提出するために必要なものを参照すると、「宣言型」は、いわゆる
「宣言APIは、」地元の元YAMLファイルの中身を気にすることなく、APIオブジェクトを修正するためのパッチの途中に複数の書き込み側のAPIを可能に
Kubernetesプロジェクトは、APIの成長目標、削除、変更、外部からの介入なしに完全な場合にチェック、「実際の状態」と「望ましい状態」のチューニングに関する完全な（リコンサイル）プロセスに基づくことができます
コア宣言型APIは、どこKubernetesプロジェクトスケジューリング機能「生存」です
AdmissionControlメカニズム
総K8SポッドまたはAPIServerのに提出されたAPIオブジェクト後に実行する必要がある場合
、そのような特定の自動ラベルとして初期化動作は、ポッドを加え
、これらの機能は、コントローラが選択的にコンパイルするために実装することができる入場に頼る達成します
オブジェクトが作成されAPIServer APIが呼び出されます後すぐに
、あまりにも多くの問題を追加APIServer独自のルールを再コンパイルする必要があります
ホットスワップ可能なアドミッションメカニズム（ダイナミックアドミッション）
Istio実装メカニズム
コンテナ初期化子の独自の定義を自動的に注入し、すべてのポッドの書き込み1に
ザ・初期化子定義がConfigMapの道にクラスタに保存されます
ユーザーの更新は初期化子ポッドの中でオブジェクトをするとき、あなたは完全にパッチのAPIを使用する必要があります
Istio意志初期化子がクラスタとしてK8Sポッドで良い走行を書く
ポッドYAMLファイルでK8Sに提出した後は、自動的にAPIの特使コンテナ設定が良いポッドを作成するオブジェクトを追加します
はじめに初期化初期化子
初期化子は、クラスタ内で実行ポッドの形であってもよい
初期リア初期化子は、いくつかのカスタムプロパティを追加するいずれかのAPIオブジェクトでちょうどオブジェクトに即座に作成されていることを意味し、デバイスを初期化することで呼び出します
やるべき初期化作業が自動的にAPIに追加され、関連する分野の定義のこの部分は、ポッドは、ユーザーが提出したオブジェクトを分離することである。しかし、ポッドはフィールドにユーザーが提出し、既にコンテナとボリュームフィールドを持っています
従ってKubernetes更新要求を処理するとき、gitのマージと同様、このような操作を使用する必要があるなど、一緒に両容器の最終的な内容を作成し、ボリュームをマウントするために組み合わせることができる合成の結果に応じて、
イニシャライザ更新されたユーザオブジェクトをポッドPATCHのAPIを実行する必要があります使用しますが、最も重要なのは、宣言APIの能力のPATCHのAPIであるとき、
能力がAPIにできK8Sオンラインアップデートオブジェクト
初期化ロジックの流れ
1.まず、ConfigMapから関連するデータが空のポッドは、オブジェクトを作成得るために
2ポッド呼び出しK8S TwoWayMergePatchリターンデータパッチ内のパラメータとして2つの古いものと新しいオブジェクトを
3.クライアントによるPATCHは、元のポッドオブジェクトを更新するためのリクエストを送信します
ポッドは、ユーザーが送信した「自動注入」、それは自動的に完全特使コンテナをKubernetes初期化特性を利用した特使コンテナ関連のフィールドを追加します原則としてオブジェクト
宣言型APIの設計
APIへのフルパスがEtcd内のオブジェクトと同じオブジェクトからなるグループ/バージョン/リソースAPIによってで複数のAPIバージョンVersion K8S BEの重要な手段を持つことができます
APIに一致するオブジェクトの1.最初のグループ
ポッドNodeオブジェクトコアAPIでそのグループグループが直接「」から/ API検索である必要はありません。
K8Sの型定義を見つけるために、フィールドにユーザーが提出したYAMLファイルを使用するために完全なパスに基づいてインスタンスを作成します。2.
インスタンスの作成プロセスでは、スーパーバージョンのオブジェクトにユーザーが提出したYAMLファイルをオンに変換操作になります
YAMLの異なるバージョンを提出するAPIのリソースフィールドのすべてのバージョンユーザーフレンドリーなAPIの全集のタイプです
3.検証初期化子操作とAPIオブジェクトの操作
レジストリは、それがK8Sで有効なオブジェクトレジストリAPIで、その後見つけることができますすることができ、各フィールドの標的の確認、検証APIオブジェクトの妥当性検証動作のデータ構造を定義するために保存しました
4.ターゲット・ユーザーにオブジェクトを格納するために、スーパーバージョン変換は、シーケンスのバージョンを提出しetcd
カスタムAPIのリソースタイプ（CRD）
CRDが正常にちょうど半分の作業を完了し、宣言APIを作成した後
ので、CRDにのみCRUD操作をK8Sコントローラは、CRDのために作成されていないので、
しかし、トリガー対応ビジネスCRUD操作はCRDに場所の件名を取ることができません各ビジネス・ロジック・コードは、オブジェクトときに変更がトリガコントローラ内のCRDを発生したときは、CRD CRDが達成され、対応する論理コントローラを作成する必要があります
「レジストリ」の役割はAPIServerへの登録タイプ（タイプ）である。これは、ネットワーク（CRD）のリソースの作業APIServerサーバーの種類の登録に自動的に完全に私たちを助けます
しかし、対応するには、我々は、クライアントがネットワークリソースタイプの定義を「知る」ことができますようにする必要があります。これは、register.goファイル（V1 / register.go）を追加するために私たちを必要とするプロジェクトに
カスタムコントローラ
1.主な機能書く
2.書き込みコントローラ定義カスタム
ビジネスロジックコントローラの調製
情報提供の仕組み
リフレクタは、イベント通知受信する変更のインスタンス一旦オブジェクトインスタンスの変更をキャプチャし、監視するためのリフレクタ使用ListAndWatch法
（イベントおよびオブジェクト）の通知を受信した後、キューをFIFOの組み合わせに
情報提供は、キューからイベントの種類を決定するために、オブジェクトを読んで、その後の仕事のローカルキャッシュローカルキャッシュの同期オブジェクトを作成または更新し続けることは情報提供の重要な責務であります
情報提供者の第二の義務は、イベントの種類に応じて、トリガ、予め登録良いResourceEventHandlerにあります
イベントの変化を聞くことによって、インフォーマは、リアルタイムのローカルキャッシュに更新することができ、これらのイベントを呼び出すまで対応のEventHandler
、インフォーマは、ローカルキャッシュを維持するすべてのresyncPeriod指定時間後には、最新のLISTの結果を使用しますが、一度更新を強制するために戻りましたキャッシュの実効性を確保
いわゆるインフォーマは、ネイティブキャッシングとインデックス機構は、ハンドラのクライアントライブラリをトリガすることができます。
ローカルキャッシュにクライアントとパッケージ.Reflectorフォーマの間、一般的に、一般的に、Kubernetesストアと呼ばれる指標がIndex.Informerリフレクターパッケージを使用と呼ばれ、それはで、ListAndWatchのAPIメカニズムによって、オブジェクトの変更を取得し、監視することができます「FIFOキュー増分」協力します。
制御周期の間に情報提供し、あなたが書きたいが、その後の共同作業にキューを使用しています。実際には、すべての制御に加えて、実際にKubernetesが自動的に生成、コード以外のループ
ロジック制御ループ
1.待ちフォーマローカル・キャッシュ・データの同期化を完了
2.スタート1つ以上のタスクの無限ループがゴルーチン
ビジネス・ロジック・コードの各サイクルで実行3.ユーザーが本当に気にされた
コントロール場合は1を命令は論理情報を削除するために実行される情報提供キャッシュ内の対応するオブジェクトを取得しない循環
オブジェクトが所望の状態を実行するために、キャッシュ・コントローラから情報を取得する場合は2を、実際の対比状態自体が由来するクラスターの実際の状態から所望の状態をetcd
カスタムAPIのリソースで使用することができ、デフォルトのターゲットに使用することができないだけで、このプロセスは、ネイティブAPI Kubernetes
、このカスタムコントローラを作る、と私は、カスタムAPIのAPIオブジェクトとデフォルトのオブジェクトは、共同作業を行うことができより複雑なオーケストレーションを達成するために
ただ、「本当の状態」とどのように「望ましい状態」と話をするそれを得るために比較を行うを取得する方法に焦点を当てる必要がある、次のことを決定するためには、このアイデアKubernetes APIプログラミングパラダイムへのコアビジネスロジックがあります