著者|王Guoliang Kubernetesコミュニティメンバーとプロジェクトのメンテナのオリジナルタイトル「道路のKubernetesアプリケーション：Kubernetes着陸してみましょう」ほとんど朱書き知ってから3つの軸を「」：元のアドレスをクラウドコンピューティングの猛攻撃：https://zhuanlan.zhihu.com / P / 82666719
生まれ裕福、メーカーの裏書Kubernetesオープンソースプロジェクトは、2014年6月以来、多くのベンダーやオープンソースの愛好家の共同の努力の急激な上昇は、今日は、コンテナ管理の分野におけるデファクトスタンダードに成長しました。高度な設計コンセプト、オープン参加のしきい値、国内外のメーカーや開発者の強力なサポートにより、その成功は自明です。
Kubernetes熱
Kubernetes主要なクラウド・ベンダーなどの後に求められ、国内および国際的な動向、この波、アリゴールドのドレス、Jingdongは、米国のグループは、低下し、他の大手企業、インフラストラクチャの焦点とみなさKubernetes、「一千人が1万目を持っていますKubernetesは、コンテナ管理の分野でのデファクトスタンダードですが、ビジネスで実際に異なる背景には、地面に差があるものの、ハムレット」は、Kubernetesの方法です。これは、大きく3つのカテゴリに分けることができます。
一つは、完全にそのネイティブモードおよびアプリケーションでKubernetes（上）に配備され、これらのユーザーのほとんどは新興の数、過度の負担なしに技術スタックであり、主にパブリッククラウドを利用してKubernetesプログラムやサービスに集中しています;
一つは、構築されたKubernetesコンテナ管理プラットフォーム（オン）の概念とKubernetesの一部を再利用しますが、比較的長い時間を管理するためにKubernetesアプリケーションに管理する古いサービスのガバナンスを維持し、そのような企業の発展はなかったに基づいています技術重い負担、すぐにこれらのユーザーは主に、いくつかの中規模または大規模プライベートクラウドKubernetesでシーンを使用し、長年にわたって蓄積した技術を放棄することが一時的にできない、クラウドサービスガバナンスのネイティブに切り替えることはできません。
他には、現在の管理アプリケーションで対処し、ローカライズされたアプリケーション管理によって需要、およびKubernetesネイティブアーキテクチャへのローカライズされた負荷の管理に適応するための負荷のカスタムアプリケーション（で）Kubernetesデザインコンセプトに基づいており、トレンド、両方のネイティブとクラウド配当はKubernetesコミュニティを食べるだけでなく、ネイティブがクラウド大きな道路を採用している、一つに、蓄積した技術開発の年の進化をより良くするために。
財団「斧」：上記Kubernetes
私たちは、あなたがコンテナ管理プラットフォームを選択させた場合、私は誰もKubernetesを選択し、任意の技術的な負担なしに、特にユーザーのために、Kubernetesを逃すべきではないと信じて間違いなく最も賢明な選択です。
Kubernetesの上に、この方法はよく理解されて着陸、それはあなたがネイティブ、基準を置くことで、任意の連絡先やコミュニティのバージョンなしKubernetesの侵襲的な変化は、それを持ってきて、ランニングは直接完全Kubernetesの上に独自のアプリケーションを構築、展開することができます標準Kubernetes APIを介してクラスタにアクセスします。あなたは完全にすべてのあなたのKubernetesを維持するために、コミュニティの力であり、コミュニティのペースを維持するために、あなたのKubernetesをアップグレードするために、コミュニティの進化をたどることができます。
これは、あなたが主流のコミュニティや業界の外に考慮しなければならないが、間違いなく落ちるための最良の方法ですが、また、管理・運用・保守のコストを削減します。
上に示したように、あなたがKubernetesを着陸に標準、主流のクラウドネイティブシステムをインストールすることができ、あなたは社会基盤プログラムの完全なセットを採用し、あなたのニーズを満たすために十分なことができます。
高次「斧」：Kubernetesオン
確かに非常に優れたネイティブKubernetesクラスタを使用することができますが、いくつかのシーンは、必ずしも通過しません。我々はすべて知っているように、Kubernetesのコンセプトとデザインは、実際には非常に高度で、Googleのソフトウェアの開発と応用展開哲学は十分に良いですが、業界のビジネスや時代遅れの技術の概念と、より複雑なシーン、ビジネスの技術的な蓄積によっていくつかの最もユーザーは、突然のすべては、いくつかのために実際にネイティブKubernetesのアプリケーションの導入と管理にあまりを、現在のアプリケーションの管理と展開モードを放棄することを望んでいます。これらのユーザーのために、あなたは確かに他の人が肉まんを食べて見て自分自身をかむことはできません。
Kubernetesフロアに、一方では、このようなサービス等の管理、監視、ネットワークトポロジ、などの既存のインフラストラクチャを、放棄するのは難しい、それは実際に妥協し、プロセスの途中で形成するだけでネイティブに基づいていくつかのローカライズされたKubernetesを行うことができますKubernetesので変換は、現在のアプリケーションの管理を満たすために、例えば放棄KUBEプロキシ監視エージェント等リッチ容器によって、ネットワーク内のパッケージ部品の一部を平坦化環境を使用します。
一方で、この秋の道はほとんど変化が技術のボーナスのこの波を食べることができ、1は、独自のクラウドネイティブの道を探ることができます行うことができ、内部の技術スタックはまた、クラウドネイティブの方に進化発展させ、この波ではないだろうことができこれまでのトレンドの背後にあるが、また、あなたは、独自のカスタマイズされたKubernetes開発シーンに応じて行うことができ、さらには未解決のいくつかの問題を解決するために遠くKubernetesコミュニティやコミュニティよりも行きます。
利益はもののKubernetesの設計と管理機能によって、失われますが、同時にによる変換のローカライズに、アップグレードは多くの問題になりますKubernetesコミュニティのバージョンと完全に互換性がないことができ、私はまた、各アップグレードパッチを戦わなければなりませんでしたKubernetesのジレンマの複数のバージョンを維持すると同時に表示されます、これは間違いなく多くの問題をもたらす開発・運用・保守をあるので、これは、道路を通過するいくつかのR＆Dと技術力を取るために普通の中小企業ではありません。典型的なアリババシグマ、米国のグループ投稿HULK 2.0とJingdongはJDOS 2.0。
米国ミッションはHULK2.0レビュー
ゲームが再生され、このハイエンドでは、唯一独自のプログラムを満たすために、標準的なルーチンはありません。このようKubernetesにHULK2.0システム構築、既存の設備と併せて、米国のグループとしてコメントなどのストレージ、ネットワーキング、負荷のライフサイクル管理およびアプリケーション監視、中にローカライズされた変換を行うが、Kubernetes APIの完全な互換性が残っています。あなたも、このような網易のクラウドベースKubernetesとしてKubernetes深さのカスタマイズを、行うために、自分のニーズやビジネスシナリオに応じて、その上のコンポーネントの統合のシリーズをリリースし、ストレージ、監視、リンクトラッキング、サービスやネットワークなどのインフラを所有することができますカスタマイズの練習の深さ。
ロア「斧」：Kubernetesで
クラウドネイティブこの文は、広く技術の円内に循環されてきた、とさえ一部の学生は、クラウドネイティブが何であるかを理解していないが、彼らはネイティブのクラウドの発展に向けて進化を知っています。いずれの場合も、ユーザーにとっては、過去に導入および管理サービスだけでなく、仮想マシンの管理戦略を変更する必要があります。Kubernetesのすべてがトレンドである、と言っている、CRDは、我々は、拡張Kubernetesの生産を完了するための能力を持つことができることを意味GA、先週リリースされたバージョン1.16にKubernetes 1.7バージョンから生成されました。
我々はKubernetesがあります理解していれば、Kubernetes自体は、多くの機能を提供することにKubernetesほかのプラットフォームである：例えば、それは、開発スピードを高速化するワークフローアプリケーションを簡素化することができ、ユーザーが独自の方法組織と資源の管理にラベルを使用することができます。また、こうした状況のチェックなどのカスタムリソース、から記述情報を使用して注釈は、管理ツールを提供しています。また、Kubernetesコントローラは、開発者とユーザと同じAPI上に構築され、ユーザーはまた、独自のコントローラおよびスケジューラを書くことができ、それはまた、システムのプラグイン機構の拡大の様々なを介して機能することができます。
これは、我々は、あなたが複雑な技術スタックは、複雑なワークフロー、何の問題を持っているかを取り除くことができない持っている場合でも、内部APIや負荷の種類Kubernetesを拡張することによって、アプリケーションおよび負荷管理方法のいずれかの形式や種類をあなたがすることができます完了できることを意味しますその任意の外部依存関係と論理リソースを投入する必要があり、アプリケーションのライフサイクルに応じました。
この方法で、床には、Kubernetesの設計と管理理念に実際にKubernetesによって提供拡張メカニズム、完全にローカライズされた、複雑なロジックであるだけKubernetesを使用していないが、統合とネイティブKubernetesを弱め、各エンドユーザーそれはユニークなKubernetesの独自のセットを持っています。あなたは私を持って、私はあなたを持っています。また、それはまだ完全な互換性とネイティブKubernetes、優雅にアップグレードして、パッチ合併コミュニティなどがあります。アリはOpenkruiseオープンソースプロジェクトのより代表的です。https://github.com/openkruise/kruise
ユーザーKubernetesコアは、実際には、大きな理由は、ユーザが良い試合することはできませんKubernetes現在のワークロード管理とKubernetes既存のワークロード・タイプで選択することで、ワークロードの管理です。CRDとオペレータは、ユーザーが自分の負荷をカスタマイズできるようにすることで、この問題を解決します。OpenKruiseプロジェクトは典型的な例であり、それは、スケーラビリティグループコントローラとKubernetesコア制御ワークロード管理を補完します。例えば、これは3つのワークロード・コントローラを提供します。
- シニアStatefulSet：デフォルトStatefulSet強化されたバージョンは、そのようなインプレース更新、pasueとMaxUnavailableなどの追加機能を持ちます。
- BroadcastJob：実行ポッドは、クラスタ内のすべてのノードでの作業を完了します。
- SidecarSet：注射ポッドは選択仕様によれば、コントローラは、容器をサイドカーし、容器がサイドカーをアップグレードすることができます。
理想的には、任意の負荷もKubernetes自身の負荷管理Kubernetes、全てを行うことができ、すなわちオンKUBE-KUBE、などなどMySQLクラスタオペレータ、などのステートフルサービスに対する管理、あなたはoperatorhubのいくつかを見つけることができます非常に古典的な例。
概要
相互の道を着陸の違いが、実際には異なるコンテキストで最良の選択であるが、これらはAPI完全に互換性Kubernetesすることができ、問題自体の外に、私たちは最適な方法と言うことはできません。
Kubernetes上：あなたはスタートアップ企業であれば、私たちはそこには負担がありませんが、また、独自のKubernetesを維持するために余裕がない、人材の欠如、通常の使用Kubernetes容器管理やサービスの展開に会いたいです。
Kubernetes上：あなたがしている場合、中規模、さらには大企業が蓄積された技術や設備の多くを持っている、とあなたのニーズを満たしていない能力と人間の適応と開発KubernetesまたはネイティブKubernetesを持っています。
Kubernetesに：あなたは、単にKubernetesまたはネイティブKubernetesを使用して満足していないニーズを満たすことができない、あなたが変更することができます上記Kubernetesから来て、もちろん、あなたが懸命に働く、あるいは完全に現在のインフラストラクチャとアプリケーションの管理を変換したい、したい場合クラウドネイティブ道路に近いか、古いマシンの展開と配信モデルをアップグレードしたい、あなたはKubernetesのすべての最後の、Kubernetes上から来る変更することができます。
ランディングKubernetesの方法が似ているのですか？
「アリババクラウドネイティブマイクロチャネルパブリック番号（ID：Alicloudnative）フォーカスマイクロサービスで、サーバレス、コンテナ、サービスメッシュ及び他の技術分野、クラウドネイティブで人気の技術動向を中心に、クラウドネイティブの大規模な着陸の練習は、ほとんどがクラウドネイティブ開発を理解してください技術公衆番号。」