この記事はRancherLabsから転送されました
著者について
VIGNESH TV、Timecampus CEO、CTO、創設者。
Kubernetesは現在最も人気のあるオープンソースコンテナオーケストレーションプラットフォームであり、多くの企業がインフラストラクチャを構築するための最初の選択肢となっています。この記事では、ユースケースのインフラストラクチャを構築するための最良の方法と、さまざまな制約に基づいて行う必要のあるさまざまな決定について説明します。
建築デザイン
アーキテクチャはユースケースを中心に大部分を設計する必要があるため、インフラストラクチャがユースケースをサポートできるように設計プロセスに細心の注意を払う必要があります。また、必要に応じて外部の専門家チームに支援を求めることもできます。アーキテクチャ設計の最初の方向が正しいことを確認することは非常に重要ですが、これは間違いが発生しないことを意味するものではなく、新しいテクノロジーや研究が毎日出現するにつれて、変化が標準になり、あなたのアーキテクチャデザイン思考は時代遅れかもしれません。
そのため、Architect for Changの原則を採用し、アーキテクチャをモジュラーアーキテクチャにして、将来必要になったときに内部で柔軟に変更できるようにすることを強くお勧めします。
クライアント/サーバーモデルを考慮して、システムアーキテクチャの目標を達成する方法を見てみましょう。
エントリポイント：DNS
一般的なインフラストラクチャ（クラウドネイティブアーキテクチャであるかどうかに関係なく）では、メッセージ要求を最初にDNSサーバーで解決し、サーバーのIPアドレスを返す必要があります。DNSの設定は、必要な可用性に基づいて行う必要があります。より高い可用性が必要な場合は、サーバーを複数のリージョンまたはクラウドプロバイダーに分散することをお勧めします。具体的な実装は、達成したい可用性のレベルに基づいている必要があります。
コンテンツ配信ネットワーク（CDN）
場合によっては、サーバーの負荷を軽減しながら、できるだけ遅延を最小限に抑えてユーザーにサービスを提供する必要があります。ここで、コンテンツ配信ネットワーク（CDN）が重要な役割を果たします。
クライアントはサーバーに静的アセットのセットを要求することがよくありますか？サーバーの負荷を減らしながら、ユーザーへのコンテンツ配信の速度を上げたいですか？この場合、エッジCDNを使用して静的資産のグループにサービスを提供すると、実際にはユーザーの待ち時間とサーバーの負荷を減らすのに役立つ場合があります。
すべてのコンテンツは動的ですか？複雑さを軽減するために、ある程度遅延したコンテンツをユーザーに提供できますか？または、アプリケーションは非常に低いトラフィックを受信しますか？この場合、CDNを使用してもあまり意味がない場合があります。すべてのトラフィックをグローバルロードバランサーに直接送信できます。ただし、CDNを使用すると、トラフィックを分散できるという利点があります。これは、サーバーがDDOS ***の影響を受ける場合に非常に役立ちます。
CDNプロバイダーにはCloudfareCDN、Fastly、Akamai CDN、Stackpathが含まれ、クラウドプロバイダーはGoogle CloudPlatformのCloudCDN、AWSのCloudFront、MicrosoftAzureのAzureCDNなどのCDNサービスも提供する場合があります。
ロードバランサー
CDNで処理できないリクエストがある場合、そのリクエストは次のステップでロードバランサーに送信されます。これらは、リージョナルIPまたはグローバルエニーキャストIPにすることができます。場合によっては、ロードバランサーを使用して内部トラフィックを管理することもできます。
ロードバランサーは、トラフィックを適切なバックエンドサービスにルーティングおよびプロキシするだけでなく、SSLターミネーション、CDNとの統合、さらにはネットワークトラフィックの特定の側面の管理も担当できます。
ハードウェアロードバランサーはありますが、ソフトウェアロードバランサーは強力な柔軟性、コストの削減、および弾力性のあるスケーラビリティを提供します。
CDNと同様に、クラウドプロバイダーもロードバランサー（GCPのGLB、AWSのELB、AzureのALBなど）を提供できる必要がありますが、さらに興味深いのは、これらのロードバランサーをKubernetesデバイスから直接デプロイできることです。 。たとえば、GKEで入力を作成すると、バックエンドでトラフィックを受信するためのGLBも作成されます。入力を構成することで、CDNやSSLリダイレクトなどの他の機能も設定できます。詳細を表示するには、次のリンクにアクセスしてください。
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
最初は常に小さいものから始めますが、ロードバランサーを使用すると、次のスケールでアーキテクチャに徐々にスケーリングできます。
ネットワークとセキュリティのアーキテクチャ
次に注意するのはネットワークです。セキュリティを向上させたい場合は、プライベートクラスターが必要になる場合があります。そこでは、インバウンドとアウトバウンドのトラフィックを規制したり、NATの背後にあるIPアドレスをブロックしたり、複数のVPC上の複数のサブネットのネットワークを分離したりできます。
ネットワークの設定方法は、通常、探している柔軟性の程度とその実装方法によって異なります。正しいネットワークを設定することは、通常の操作を維持しながら
、表面を可能な限り減らすことです。適切なネットワークを設定してインフラストラクチャを保護するには、通常、適切なルールと制限を備えたファイアウォールを使用して、インバウンドとアウトバウンドを含むさまざまなバックエンドサービスからのトラフィックの送受信を制限します。多くの場合、要塞ホストを設定し、トンネルを介してクラスター内のすべての操作を実行することで、これらのプライベートクラスターを保護できます。これは、パブリックネットワークに公開する必要があるのは要塞（ジャンプホストとも呼ばれます）であり、通常は設定内のクラスターと同じネットワーク。一部のクラウドプロバイダーは、ゼロトラストセキュリティを実現するためのカスタマイズされたソリューションも提供しています。たとえば、GCPはユーザーにIdentity Awareness Proxy（IAP）を提供します。これは、一般的な実装を置き換えるために使用できます。
すべてが完了したら、次のステップは、ユースケースに応じてクラスター自体の中にネットワークをセットアップすることです。
これには、次のタスクが含ま
れます。クラスター内でのサービス検出のセットアップ（CoreDNSで処理可能）
必要に応じて、サービスメッシュ（LinkerD、Istio、Consulなど）を設定します。
IngressコントローラーとAPIゲートウェイをセットアップします（例：Nginx、Ambassador、Kong、Glooなど）
CNIを使用してネットワークプラグインをセットアップし、クラスター内のネットワークを容易にします
ネットワークポリシーを設定し、サービス間の通信を調整し、必要に応じてさまざまなサービスタイプを使用してサービスを公開します
GRPC、Thrift、HTTPなどのプロトコルとツールを使用して、異なるサービス間のサービス間通信を設定します
A / Bテストを設定します。IstioやLinkerdなどのサービスメッシュを使用すると、実装が簡単になります。
実装例をご覧になりたい場合は、このリポジトリ（https://github.com/terraform-google-modules/cloud-foundation-fabric）をご覧になることをお勧めします。これは、ユーザーがこれらのさまざまなネットワークをすべてセットアップするのに役立ちます。 VPNを介したハブアンドスポーク、内部DNSとGoogleプライベートアクセス、GKEをサポートする共有VPCなどを含むGCPモデルでは、すべてTerraformを使用します。
クラウドコンピューティングのネットワークの興味深い点は、それがお住まいの地域のクラウドサービスプロバイダーに限定されず、必要に応じて複数の地域にまたがることができることです。これは、KubefedやCrossplaneなどのプロジェクトが役立つ場合があります。
VPC、サブネット、およびネットワーク全体を設定する際のいくつかのベストプラクティスについて詳しく知りたい場合は、次のWebページにアクセスすることをお勧めします。同じ概念が参加するすべてのクラウドプロバイダーに適用されます。
https://cloud.google.com/solutions/best-practices-vpc-design
知事
GKE、EKS、AKSなどのマネージドクラスターを使用している場合、Kubernetesは自動的に管理されるため、ユーザー操作の複雑さが軽減されます。
Kubernetesを自分で管理する場合は、etcdストレージのバックアップと暗号化、クラスター内のノード間のネットワークの確立、ノードに最新バージョンのオペレーティングシステムパッチを定期的にパッチする、クラスターのアップグレードを管理するなど、多くのことに対処する必要があります。アップストリームに追いつくためにKubernetesバージョンは同じままです。これに基づいて、これは、これらのものを維持するための専用チームがある場合にのみ推奨されます。
サイト信頼性エンジニアリング（SRE）
複雑なインフラストラクチャを維持する場合は、適切な可観測性スタックを用意することが非常に重要です。これにより、ユーザーがエラーに気付く前にエラーを検出して変更の可能性を予測し、異常を特定して、問題をさらに深く掘り下げることができます。 。
現在、これには、収集および分析する特定のツールまたはアプリケーションとしてインジケーターを公開するエージェントが必要です（プルまたはプッシュメカニズムに従うことができます）。また、サイドカーでサービスメッシュを使用している場合、カスタム構成を必要とせずに、サイドカーに独自のインジケーターが付属していることがよくあります。
どのシナリオでも、時系列データベースとしてPrometheusなどのツールを使用してすべてのメトリックを収集し、OpenTelemetryと同様のツールを使用して、組み込みのエクスポーターを使用してアプリケーションやさまざまなツールからメトリックを公開できます。複数のチャネルに通知とアラートを送信するAlertmanagerなどのツールの助けを借りて、Grafanaは、インフラストラクチャ全体の完全な可視性をユーザーに提供する視覚的なダッシュボードを提供します。
要約すると、これは可観測性のためのPrometheusのソリューションです。
出典：https：//prometheus.io/docs/introduction/overview/
このような複雑なシステムでは、すべてのログが1つの場所に流れてデバッグが容易になるように、ログ集約システムも使用する必要があります。ほとんどの企業はELKまたはEFKスタックを使用する傾向があり、LogstashまたはFluentDは、制約に応じてログの集約とフィルタリングを行います。しかし、ログフィールドには、LokiやPromtailなどの新しいプレーヤーもいます。
次の図は、FluentDのようなログ集約システムがアーキテクチャを簡素化する方法を示しています。
出典：https：//www.fluentd.org/architecture
しかし、複数のマイクロサービスやツールにまたがるリクエストを追跡したい場合はどうでしょうか。ここで、特にマイクロサービスの複雑さを考慮すると、分散トレースが役立ちます。ZipkinやJaegerのようなツールは常にこの分野のパイオニアであり、この分野に参入するための最新のツールはTempoです。
ログの集計ではさまざまなソースからの情報が提供されますが、リクエストのコンテキストが提供されない場合があります。これは、追跡が非常に役立つ場合です。ただし、スタックにトレースを追加すると、リクエストとともにサービス間でコンテキストを伝播する必要があるため、リクエストに多くのオーバーヘッドが追加されることに注意してください。
次の図は、一般的な分散トレースアーキテクチャです。
出典：https：//www.jaegertracing.io/docs/1.21/architecture/
ただし、Webサイトの信頼性は、監視、視覚化、およびアラートにとどまりません。システムの任意の部分の障害に対処する準備をし、バックアップとフェイルオーバーを定期的に実行して、少なくともデータ損失の程度を最小限に抑える必要があります。これは、Veleroなどのツールを使用して行うことができます。
Veleroは、使用しているのと同じKubernetesアーキテクチャを活用することで、ワークロードやストレージなど、クラスター内のさまざまなコンポーネントの定期的なバックアップを維持するのに役立ちます。Veleroのアーキテクチャは次のとおりです。ご覧のとおり
、オブジェクトを定期的にバックアップし、設定したスケジュールに従って特定の宛先にプッシュするバックアップコントローラーがあります。頻度は設定したスケジュールに基づいています。ほとんどすべてのオブジェクトがバックアップされるため、これはフェイルオーバーと移行に使用できます。
ストレージ
利用可能なストレージプログラムとファイルシステムにはさまざまなものがあり、クラウドプロバイダーによって大きく異なる可能性があります。これには、ボリュームのほとんどの外部プラグインを支援できるContainer Storage Interface（CSI）などの標準が必要です。これにより、コアのボトルネックになることなく、保守と開発が容易になります。
次の図は、通常、さまざまなボリュームプラグインをサポートするCSIアーキテクチャを示しています。
ソース：https：//kubernetes.io/blog/2018/08/02/dynamically-expand-volume-with-csi-and-kubernetes/
分散ストレージによって引き起こされるクラスタリングと拡張の問題についてはどうすればよいですか？現時点では、Cephなどのファイルシステムがその機能を証明していますが、CephがKubernetesを中心に構築されていないことを考えると、展開と管理にいくつかの困難があり、Rookなどのプロジェクトを検討することができます。
RookはCephと結合されておらず、EdgeFS、NFSなどの他のファイルシステムもサポートしていますが、RookとCephCSIは天国で行われた一致のようなものです。RookとCephのアーキテクチャは次のとおりです。
出典：https：//rook.io/docs/rook/v1.5/ceph-storage.html
ご覧のとおり、RookはKubernetesクラスターでCephのインストール、構成、管理の機能を引き受けます。ユーザーの好みに応じて、次のストレージが自動的に割り当てられます。これはすべて、アプリケーションを複雑な状況にさらすことなく行われます。
ミラー倉庫
ミラーリポジトリは、さまざまなユーザーアカウントの管理、イメージのプッシュ/プル、クォータの管理、Webhookを介したイベント通知の取得、脆弱性スキャンの実行、プッシュされたイメージへの署名を行うことができるユーザーインターフェイスを提供します。また、イメージの処理やオペレーションへのログインも可能です。複数のミラーウェアハウスでミラーをコピーするなど。
クラウドプロバイダーを使用している場合、それらはサービスとしてミラーウェアハウス（GCR、ECR、ACRなど）を提供している可能性があり、これにより多くの複雑さが解消されます。クラウドプロバイダーが提供していない場合は、Docker Hub、Quayなどのサードパーティのミラーウェアハウスを選択することもできます。
しかし、独自のミラーウェアハウスをホストしたい場合はどうでしょうか。
企業内にミラーウェアハウスを展開する場合、それ自体をより詳細に制御する場合、または脆弱性スキャンやその他の操作に関連するコストを削減する場合は、ミラーウェアハウスをホストする必要があります。
この場合、Harbourのようなプライベートミラーリポジトリを選択すると役立ちます。Harbourのアーキテクチャは次のとおりです。
ソース：https：//goharbor.io/docs/1.10/install-config/harbor-ha-helm/
Harbourは、Dockerを含むさまざまなオープンソースコンポーネントで構成されるOCI準拠のミラーリポジトリです。ミラーリポジトリV2ハーバーUI、クレアおよび公証人。
CI / CDアーキテクチャ
Kubernetesは、あらゆる規模ですべてのワークロードをホストできますが、アプリケーションをデプロイするための標準的な方法と合理化されたCI / CDワークフローも必要です。次の図は、一般的なCI / CDパイプラインを示してい
ます。TravisCI、Circle CI、Gitlab CI、Github Actionsなどの一部のサードパーティサービスには、すべて独自のCIランナーが含まれています。構築するパイプラインのステップを定義するだけで済みます。これには通常、イメージの構築、脆弱性の可能性についてイメージのスキャン、テストの実行とイメージリポジトリへのプッシュが含まれ、場合によっては、承認のためにプレビュー環境が必要になります。
これで、独自のCIランナーを管理する場合でも、手順は通常同じですが、クラスターの内部または外部に設定するように構成し、アセットをミラーウェアハウスにプッシュするための適切な権限を持っている必要があります。
総括する
Kubernetesに基づくクラウドネイティブインフラストラクチャのアーキテクチャを紹介しました。上で見たように、さまざまなツールがインフラストラクチャのさまざまな問題を解決します。それらはレゴブロックのようなもので、それぞれが特定の現在の問題に焦点を当て、あなたのために多くの複雑なものを抽象化します。
これにより、ユーザーは徐々にKubernetesを使い始めることができます。また、ユースケースに応じて、スタック全体で必要なツールのみを使用できます。