Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成

Kubernetes のベスト プラクティス。 小さなコンテナの作成

より多くの Kubernetes サービスを作成し始めると、最初は単純だったタスクがより複雑になり始めます。 たとえば、開発チームは同じ名前でサービスやデプロイメントを作成することはできません。 何千ものポッドがある場合、適切に管理することはもちろん、それらをリストするだけでも多大な時間がかかります。 そして、これは氷山の一角にすぎません。

名前空間によってどのように Kubernetes リソースの管理が容易になるかを見てみましょう。 では、名前空間とは何でしょうか? 名前空間は、Kubernetes クラスター内の仮想クラスターと考えることができます。 単一の Kubernetes クラスター内で複数の名前空間を相互に分離できます。 これらは、組織、セキュリティ、さらにはシステム パフォーマンスに関して、あなたとあなたのチームを大いに助けてくれます。

ほとんどの Kubernetes ディストリビューションでは、クラスターは「default」と呼ばれる名前空間を備えた状態で出荷されます。 実際、Kubernetes が扱う名前空間は、default、kube-system、kube-public の XNUMX つです。 現在、Kube-public はあまり使用されていません。

特に Google Kubernetes Engine のようなマネージド システムでは、kube 名前空間をそのままにしておくのが得策です。 サービスとアプリケーションが作成される場所として「デフォルト」名前空間が使用されます。 Kubernetes がすぐに使用できるように構成されており、削除できないことを除けば、特別なことは何もありません。 これは、初心者や低パフォーマンスのシステムには最適ですが、大規模な本番システムではデフォルトの名前空間を使用することはお勧めしません。 後者の場合、ある開発チームが他の人のコードを簡単に書き換えて、気付かないうちに別のチームの作業を中断してしまう可能性があります。

したがって、複数の名前空間を作成し、それらを使用してサービスを管理可能な単位に分割する必要があります。 名前空間は XNUMX つのコマンドで作成できます。 test という名前空間を作成する場合は、コマンド $ kubectl create namespace test を使用するか、単純に YAML ファイルを作成して、他の Kubernetes リソースと同様に使用します。

$ kubectl get namespace コマンドを使用して、すべての名前空間を表示できます。

完了すると、XNUMX つの組み込み名前空間と「test」という名前の新しい名前空間が表示されます。 ポッドを作成するための単純な YAML ファイルを見てみましょう。 名前空間についての言及がないことがわかります。

kubectl を使用してこのファイルを実行すると、現在アクティブな名前空間に mypod モジュールが作成されます。 これは、変更するまでデフォルトの名前空間になります。 リソースを作成する名前空間を Kubernetes に伝える方法は 2 つあります。 XNUMX つ目の方法は、リソースの作成時に名前空間フラグを使用することです。

XNUMX 番目の方法は、YAML 宣言で名前空間を指定することです。

YAML で名前空間を指定すると、リソースは常にその名前空間に作成されます。 名前空間フラグの使用中に別の名前空間を使用しようとすると、コマンドは失敗します。 ここでポッドを見つけようとしても、見つけることはできません。

これは、すべてのコマンドが現在アクティブな名前空間の外で実行されるために発生します。 ポッドを見つけるには、名前空間フラグを使用する必要がありますが、特に独自の名前空間を使用し、すべてのコマンドにそのフラグを使用したくないチームの開発者である場合、これはすぐに古くなります。 これを修正する方法を見てみましょう。

デフォルトでは、アクティブな名前空間はデフォルトと呼ばれます。 リソース YAML で名前空間を指定しない場合、すべての Kubernetes コマンドはこのアクティブなデフォルトの名前空間を使用します。 残念ながら、kubectl を使用してアクティブな名前空間を管理しようとすると失敗する可能性があります。 ただし、このプロセスをはるかに簡単にする Kubens と呼ばれる非常に優れたツールがあります。 kubens コマンドを実行すると、アクティブな名前空間が強調表示された状態ですべての名前空間が表示されます。

アクティブな名前空間をテスト名前空間に切り替えるには、$kubens test コマンドを実行するだけです。 $kubens コマンドを再度実行すると、新しいアクティブな名前空間が割り当てられていることがわかります (test)。

これは、テスト名前空間でポッドを確認するために名前空間フラグが必要ないことを意味します。

このようにして、名前空間は相互に隠蔽されますが、相互に分離されることはありません。 ある名前空間内のサービスは、別の名前空間内のサービスと非常に簡単に通信できるため、多くの場合非常に便利です。 異なる名前空間間で通信できるということは、開発者のサービスが、異なる名前空間にある別の開発チームのサービスと通信できることを意味します。

通常、アプリケーションが Kubernetes サービスにアクセスする場合は、組み込みの DNS 検出サービスを使用し、アプリケーションにサービスの名前を付けるだけです。 ただし、これを行うと、複数の名前空間に同じ名前でサービスを作成できますが、これは許可されません。

幸いなことに、これは DNS アドレスの拡張形式を使用することで簡単に回避できます。 Kubernetes のサービスは、共通の DNS テンプレートを使用してエンドポイントを公開します。 次のようになります。

通常、必要なのはサービス名だけで、DNS が完全なアドレスを自動的に決定します。

ただし、別の名前空間のサービスにアクセスする必要がある場合は、単純にサービス名と名前空間名を使用します。

たとえば、テスト名前空間内のサービス データベースに接続する場合は、アドレス データベース (database.test) を使用できます。

prod 名前空間のサービス データベースに接続する場合は、database.prod を使用します。

本当に名前空間へのアクセスを分離して制限したい場合は、Kubernetes では Kubernetes ネットワーク ポリシーを使用してこれを行うことができます。 これについては次のエピソードで話します。

「名前空間は何個、何の目的で作成すればよいですか?」という質問をよく受けます。 管理されたデータとは何ですか?

作成する名前空間が多すぎると、邪魔になるだけです。 それらの数が少なすぎると、そのようなソリューションの利点がすべて失われます。 すべての企業が組織構造を構築する際には、主に XNUMX つの段階を通過すると思います。 プロジェクトまたは会社の開発段階に応じて、適切な名前空間戦略を採用することが必要になる場合があります。

あなたが 5 ～ 10 個のマイクロサービスの開発に取り組んでいる小さなチームの一員であり、すべての開発者を 2 つの部屋に簡単に集めることができると想像してください。 この状況では、すべての本番サービスをデフォルトの名前空間で実行することが合理的です。 もちろん、より柔軟性を高めるために、prod と dev に別々に XNUMX つの名前空間を使用することもできます。 そしておそらく、Minikube などを使用して、ローカル コンピューターで開発をテストします。

状況が変わり、現在、急速に成長しているチームが一度に 10 を超えるマイクロサービスに取り組んでいるとします。 prod と dev に別々に複数のクラスターまたは名前空間を使用する必要がある場合があります。 チームをいくつかのサブチームに分割して、各チームが独自のマイクロサービスを持ち、各チームが独自の名前空間を選択して、ソフトウェア開発とリリースの管理プロセスを容易にすることができます。

チームの各メンバーがシステム全体がどのように機能するかについて洞察を得るにつれて、すべての変更を他のすべての開発者と調整することがますます困難になります。 ローカル マシン上でフルスタックをスピンアップすることは、日に日に困難になってきています。

大企業では、開発者は通常、誰が正確に何に取り組んでいるのかを知りません。 チームはサービス コントラクトを使用して通信するか、Istio 構成ツールなどのネットワーク上に抽象化レイヤーを追加するサービス メッシュ テクノロジを使用します。 スタック全体をローカルで実行することは不可能なので、Kubernetes 上の Spinnaker のような継続的デリバリー (CD) プラットフォームを使用することを強くお勧めします。 したがって、すべてのコマンドが必ず独自の名前空間を必要とする時点が来ます。 各チームは、開発環境と本番環境に複数の名前空間を選択することもできます。

最後に、ある開発者グループが他のグループの存在すら知らない大規模な起業家企業も存在します。 このような企業は通常、十分に文書化された API を通じて対話するサードパーティ開発者を雇用する場合があります。 このような各グループには、いくつかのチームといくつかのマイクロサービスが含まれています。 この場合、先ほど説明したすべてのツールを使用する必要があります。

プログラマはサービスを手動で展開してはならず、サービスに関係のない名前空間にアクセスすべきではありません。 この段階では、構成が不十分なアプリケーションの「影響範囲」を減らし、請求プロセスとリソース管理を簡素化するために、複数のクラスターを用意することをお勧めします。

したがって、組織で名前空間を適切に使用すると、Kubernetes をより管理しやすく、制御しやすく、安全かつ柔軟にすることができます。

Kubernetes のベスト プラクティス。 Readiness および Liveness テストによる Kubernetes の Liveness の検証

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com