https://blog.ihypo.net/15642142854314.html
背中、CRD上のいくつかの記事を書くために意図された6 KubeConの終了後、Twitterはまた、CRDを改善するためのコミットメントが関連文書に多くのことを少し、こまごまとを与え、今紙にペンを置くために時間を持っていました。しかし今月、私は内部CRDのシェアを持っていた、2 CRDデモは、同僚、クライアントに、人々の数は、それが何であるかを説明しますが、私はこの事で、より明確にしましょうCRD。
私は、これは単にCRDは何かについて話を最初に、CRDを導入された2件のまたは3の記事になります。
あまりにも長いバージョンを見てはいけません。
CRD自体は、リソースKubernetesは、自身が新しいリソースタイプをカスタマイズすることができている
我々はまた、独自のロジックを実装するようにコントローラを提供CRDを除いて
、CRDは、既存のリソースに基づいて、私たちにKUBEを可能にするクラスタ容量を拡張
CRDの私たち自身の定義を行うことができます作るの概念以来、システムへの一連の仕様、
CRDが何であるかを
CRD自体がKubernetesがビルトインされているリソースの種類は、あなたがkubectl取得することにより、クラスタ内で定義されたCRDのリソースを表示するために命令することができるCustomResourceDefinitionの略語です。
kubectl GET CRD
NAMEで作成された
apps.app.o0w0o.cn 2019-07-25T07：02：47Z
microservices.app.o0w0o.cn 2019-07-25T07：02：47Z
、後の人が話をして、よりトークCRDと誰もCRDを見つけたときいくつかの共通の神話は、それゆえ、いくつかの概念を事前に明確にする必要があります。
Kubernetesでは、すべてのものは、それが記載された種類のアイテムでYAMLをされ、リソース（資源）と呼ばれている
が、のような、KUBEはCRであるユーザー定義のリソース（カスタムリソース）、許可する一般的な組み込みのリソースの展開に加えて、
CRDを（我々はそれがどんなものか定義したリソースを記述するために）実際には、ないカスタムリソースが、私たちのカスタムリソース定義
CRDのために、その本質はKuberブログの記事（のような、オープンなAPIのスキーマですhttps://kubernetes.io/blog/2019/06/20/crd-structural-schema/は）法的、ノルムであるが、どのようにYAMLを説明リソースを確保するために、記述する必要があるかどうか、またはCR R YAML、言及しました、それは、その機能の面で、CRD観光名所のスキーマで、それがどのようにどのような資源の法的定義、新しいクラスタリソースを登録し、ApiServerを通知することです。
コントローラモードは、
前に具体的にCRDを簡単にコントローラモードを説明します。Kubernetesは、我々が展開ポッドを作成することにより、管理することができることを知っている、知っていたが、実際に直接展開ポッドを作成していないが、展開管理のRS、および実際にコントローラモードで管理ポッドを、RS。
既存のリソース・モデルに基づいてコントローラの作品は、私がKubernetesコントローラで事務Yanglao濡れた記事を」称賛、当然のことながら、具体的な詳細は、より複雑で、より複雑な達成する能力は、より高次のコントローラを定義できます「（https://www.yangcs.net/posts/a-deep-dive-into-kubernetes-controllers/）
CRDを行うことができ
、通常の状況下で、我々は定義されたCR CRDを使用すると、新しいコントローラであり、我々は、ロジックコントローラを自己定義するいくつかのKubernetesクラスタにネイティブサポートされていない機能を行うことができます。
具体的な例が懸念されてください、私はシンプルなKubebulder CRD（作成https://github.com/Coderhypo/KubeServiceを）、内蔵のマイクロクラスタサービス管理Kubernetesを試してみてください。
私はマイクロサービスのライフサイクルを管理する責任が、アプリケーション全体のライフサイクル、およびその他呼ばれるMicroServiceの管理を担当し、アプリケーションと呼ばれる、2つのリソースを作成しました。
特定の論理構成を理解することができます。
アプリケーションが複数のMicroServiceを管理することができ、各MicroServiceは複数のバージョンをサポートする複数のバージョンを同時に展開することができるように、コントローラモードのおかげで、あなたは、各バージョンの展開MicroServiceを作成することができます。
のみを管理する場合は、アプリケーションの展開がややシンプルで、MicroServiceは、負荷分散と4〜7つのロードバランシングを実現するためには、各マイクロサービス作成サービスおよび入力をサポートしています。
ロードバランシング機能は、各バージョンは、サービスを作成しますMicroService、オンになっている場合は、それゆえ、我々は、n + 1のサービスを持つことになりますと、nは各バージョンであるSVCは、持っている、そして追加の1マイクロサービス作成後に（名前とCLUSTERIP）SVCの変更はありません、とSVCとセレクタはSVCの一貫CurrentVersionのままになります。
換言すれば、他の構成要素は、サービスの特定のバージョンにアクセスするための方法でありながら、安定したSVCは、他のコンポーネントにサービスの現在のバージョンを提供することができるあります。SVC + CurrentVersionのは非常に容易に解除青緑色の能力を達成します。
SVCに加えて、ロードバランスがカナリア構成に変更されとも、解放機能灰色を達成する能力nginxの進入制御に基づいMicroServiceは比例/ヘッダ/クッキー灰色のリリースで達成することができます。
この例では、アプリケーションとMicroServiceは、「新機能」を作成していないが、唯一Kubernetes既存のリソースを組み合わせて、新しい機能を実現します。
しかし、に加えて、マイクロ高速なサービス、それは、他の標準化の値を見ることはできません新しい値がない、青、緑、グレー、アプリケーションおよびMicroServiceは、アプリケーション内の任意の操作の前にはに翻訳する必要があります、の管理です展開の進入や管理は、今統一入り口標準化管理を持つことができること「KUBE言語」、。
まとめ
一般化することは非常に簡単であるかを説明するために単純で小さなデモCRDで、限り私は思った通り、私は2つの非常に重要なCRDの能力があると思います。
最初は、CRDがレゴにKubernetes既存のリソースや能力を作り、我々は簡単にKubernetesのネイティブはありません容量を拡張するためにこれらのビルディング・ブロックを使用することができ、機能的です。
、製品に続いてKubernetes製品をベースに近い用語KUBE条項に当社の製品を取得する必要性を回避していない、そのようなサービスが展開され、ポッドなどの一例です。しかし、CRDは、既存のリソースは、製品をよりむしろシーンKubernetesに適用する方法を考える方よりも、シーンを集中して解決することができますサービスのコンセプトをKUBEように、私たちは、コンセプト（またはリソース）をもとに、独自の製品を作成することができます。