高可用性 Kubernetes クラスター パターンHigh availability Kubernetes cluster pattern

この記事では、Azure Stack Hub 上で Azure Kubernetes Service (AKS) エンジンを使用して、高可用性 Kubernetes ベースのインフラストラクチャを設計し、運用する方法について説明します。This article describes how to architect and operate a highly available Kubernetes-based infrastructure using Azure Kubernetes Service (AKS) Engine on Azure Stack Hub. このシナリオは、非常に制限の厳しい規制された環境において重要なワークロードを持つ組織で一般的です。This scenario is common for organizations with critical workloads in highly restricted and regulated environments. 金融、防衛、政府機関などの領域に属する組織です。Organizations in domains such as finance, defense, and government.

コンテキストと問題Context and problem

多くの組織では、Kubernetes のような最先端のサービスとテクノロジを利用するクラウドネイティブ ソリューションを開発しています。Many organizations are developing cloud-native solutions that leverage state-of-the-art services and technologies like Kubernetes. Azure によって世界中のほとんどのリージョンにデータセンターが提供されますが、ビジネス クリティカルなアプリケーションを特定の場所で実行する必要があるエッジ ユースケースやシナリオがある場合もあります。Although Azure provides datacenters in most regions of the world, sometimes there are edge use-cases and scenarios where business critical applications must run in a specific location. 考慮事項は次のとおりです。Considerations include:

  • 場所の機密度Location sensitivity
  • アプリケーションとオンプレミス システムの間の待機時間Latency between the application and on-premises systems
  • 帯域幅の節約Bandwidth conservation
  • 接続Connectivity
  • 規制または法定要件Regulatory or statutory requirements

Azure を Azure Stack Hub と組み合わせると、これらの問題のほとんどに対処できます。Azure, in combination with Azure Stack Hub, addresses most of these concerns. Azure Stack Hub 上で実行されている Kubernetes を正常に実装するためのさまざまなオプション、決定事項、および考慮事項について、以下で説明します。A broad set of options, decisions, and considerations for a successful implementation of Kubernetes running on Azure Stack Hub is described below.

解決策Solution

このパターンは、厳格な制約セットを処理する必要があることを前提としています。This pattern assumes that we have to deal with a strict set of constraints. アプリケーションはオンプレミスで実行する必要があり、すべての個人データがパブリック クラウド サービスに届かないようにする必要があります。The application must run on-premises and all personal data must not reach public cloud services. 監視とその他の非 PII データを Azure に送信し、そこで処理することができます。Monitoring and other non-PII data can be sent to Azure and be processed there. パブリック Container Registry などの外部サービスにはアクセスできますが、ファイアウォールまたはプロキシ サーバーを通じてフィルター処理することができます。External services like a public Container Registry or others can be accessed but might be filtered through a firewall or proxy server.

ここに示されているサンプル アプリケーション (Azure Kubernetes Service ワークショップ) は、可能な限り Kubernetes ネイティブ ソリューションを使用するように設計されています。The sample application shown here (based on Azure Kubernetes Service Workshop) is designed to use Kubernetes-native solutions whenever possible. この設計では、プラットフォームネイティブ サービスを使用する代わりに、ベンダー ロックインを回避します。This design avoids vendor lock-in, instead of using platform-native services. たとえば、アプリケーションでは、PaaS サービスや外部データベース サービスではなく、セルフホステッド MongoDB データベース バックエンドを使用します。As an example, the application uses a self-hosted MongoDB database backend instead of a PaaS service or external database service.

アプリケーション パターン ハイブリッドApplication Pattern Hybrid

上の図は Azure Stack Hub 上の Kubernetes で実行されているサンプル アプリケーションのアプリケーション アーキテクチャを示しています。The preceding diagram illustrates the application architecture of the sample application running on Kubernetes on Azure Stack Hub. アプリは、次のようないくつかのコンポーネントで構成されています。The app consists of several components, including:

  1. Azure Stack Hub 上の AKS エンジン ベースの Kubernetes クラスター。An AKS Engine based Kubernetes cluster on Azure Stack Hub.
  2. cert-manager。これは、Kubernetes 内で証明書を管理するための一連のツールを提供し、Let's Encrypt に証明書を自動的に要求するために使用されます。cert-manager, which provides a suite of tools for certificate management in Kubernetes, used to automatically request certificates from Let's Encrypt.
  3. フロントエンド (ratings-web)、api (ratings-api)、データベース (ratings-mongodb) 用のアプリケーション コンポーネントを含む Kubernetes 名前空間。A Kubernetes namespace that contains the application components for the front end (ratings-web), api (ratings-api), and database (ratings-mongodb).
  4. Kubernetes クラスター内のエンドポイントに HTTP/HTTPS トラフィックをルーティングするイングレス コントローラー。The Ingress Controller that routes HTTP/HTTPS traffic to endpoints within the Kubernetes cluster.

サンプル アプリケーションは、アプリケーション アーキテクチャを示すために使用されます。The sample application is used to illustrate the application architecture. すべてのコンポーネントは例です。All components are examples. アーキテクチャには、アプリケーションのデプロイが 1 つだけ含まれています。The architecture contains only a single application deployment. 高可用性 (HA) を実現するために、2 つの異なる Azure Stack Hub インスタンス上でデプロイを少なくとも 2 回実行します。これらは、同じ場所または 2 つ (またはそれ以上) の異なるサイト内で実行できます。To achieve high availability (HA), we'll run the deployment at least twice on two different Azure Stack Hub instances - they can run either in the same location or in two (or more) different sites:

インフラストラクチャ アーキテクチャ

Azure Container Registry、Azure Monitor などのサービスは、Azure 内またはオンプレミスの Azure Stack Hub の外部でホストされます。Services like Azure Container Registry, Azure Monitor, and others, are hosted outside Azure Stack Hub in Azure or on-premises. このハイブリッド設計では、単一の Azure Stack Hub インスタンスの停止からソリューションを保護します。This hybrid design protects the solution against outage of a single Azure Stack Hub instance.

コンポーネントComponents

全体的なアーキテクチャは、次のコンポーネントで構成されます。The overall architecture consists of the following components:

Azure Stack Hub は Azure の拡張機能であり、データセンター内で Azure サービスを提供することによりオンプレミス環境でワークロードを実行できます。Azure Stack Hub is an extension of Azure that can run workloads in an on-premises environment by providing Azure services in your datacenter. 詳細については、「Azure Stack Hub の概要」をご覧ください。Go to Azure Stack Hub overview to learn more.

Azure Kubernetes Service エンジン (AKS エンジン) は、現在 Azure で利用可能なマネージド Kubernetes サービス オファリング (Azure Kubernetes Service (AKS)) の背後にあるエンジンです。Azure Kubernetes Service Engine (AKS Engine) is the engine behind the managed Kubernetes service offering, Azure Kubernetes Service (AKS), that is available in Azure today. Azure Stack Hub の場合、AKS エンジンにより、Azure Stack Hub の IaaS 機能を使用して、完全に機能するセルフマネージド Kubernetes クラスターをデプロイ、スケール、アップグレードすることができます。For Azure Stack Hub, AKS Engine allows us to deploy, scale, and upgrade fully featured, self-managed Kubernetes clusters using Azure Stack Hub's IaaS capabilities. 詳細については、AKS エンジンの概要に関するページをご覧ください。Go to AKS Engine Overview to learn more.

Azure 上の AKS エンジンと Azure Stack Hub 上の AKS エンジンの違いについては、「既知の問題と制限」を参照してください。Go to Known Issues and Limitations to learn more about the differences between AKS Engine on Azure and AKS Engine on Azure Stack Hub.

Azure Virtual Network (VNet) は、Kubernetes クラスター インフラストラクチャをホストする仮想マシン (VM) の各 Azure Stack Hub 上でネットワーク インフラストラクチャを提供するために使用されます。Azure Virtual Network (VNet) is used to provide the network infrastructure on each Azure Stack Hub for the Virtual Machines (VMs) hosting the Kubernetes cluster infrastructure.

Azure Load Balancer は、Kubernetes API エンドポイントと Nginx イングレス コントローラーに使用されます。Azure Load Balancer is used for the Kubernetes API Endpoint and the Nginx Ingress Controller. ロード バランサーは、特定のサービスを提供しているノードと VM に外部 (インターネットなど) トラフィックをルーティングします。The load balancer routes external (for example, Internet) traffic to nodes and VMs offering a specific service.

Azure Container Registry (ACR) は、クラスターにデプロイされたプライベート Docker イメージと Helm チャートを格納するために使用されます。Azure Container Registry (ACR) is used to store private Docker images and Helm charts, which are deployed to the cluster. AKS エンジンは、Azure AD ID を使用してコンテナー レジストリに対して認証できます。AKS Engine can authenticate with the Container Registry using an Azure AD identity. Kubernetes には ACR は必要ありません。Kubernetes doesn't require ACR. Docker Hub などの他のコンテナー レジストリを使用できます。You can use other container registries, such as Docker Hub.

Azure Repos は、コードの管理に使用できるバージョン管理ツールのセットです。Azure Repos is a set of version control tools that you can use to manage your code. GitHub またはその他の git ベースのリポジトリを使用することもできます。You can also use GitHub or other git-based repositories. 詳細については、Azure Repos の概要に関する記事をご覧ください。Go to Azure Repos Overview to learn more.

Azure Pipelines は Azure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。Azure Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments. Jenkins などのサードパーティ CI/CD ソリューションも使用できます。You can also use third-party CI/CD solutions such as Jenkins. 詳細については、Azure Pipeline の概要に関する記事をご覧ください。Go to Azure Pipeline Overview to learn more.

Azure Monitor では、ソリューション内の Azure サービスのプラットフォーム メトリックやアプリケーション テレメトリなど、メトリックとログが収集されて格納されます。Azure Monitor collects and stores metrics and logs, including platform metrics for the Azure services in the solution and application telemetry. このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。Use this data to monitor the application, set up alerts and dashboards, and perform root cause analysis of failures. Azure Monitor は、コントローラー、ノード、およびコンテナーからのメトリックや、コンテナー ログおよびマスター ノード ログを収集するために Kubernetes と統合します。Azure Monitor integrates with Kubernetes to collect metrics from controllers, nodes, and containers, as well as container logs and master node logs. 詳細については、「Azure Monitor の概要」をご覧ください。Go to Azure Monitor Overview to learn more.

Azure Traffic Manager は、異なる Azure リージョンまたは Azure Stack Hub デプロイにまたがってトラフィックをサービスに最適に配分できるようにする DNS ベースのトラフィック ロード バランサーです。Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across different Azure regions or Azure Stack Hub deployments. Traffic Manager により、高可用性と応答性も提供されます。Traffic Manager also provides high availability and responsiveness. アプリケーション エンドポイントは、外部からアクセスできる必要があります。The application endpoints must be accessible from the outside. 他のオンプレミス ソリューションも利用できます。There are other on-premises solutions available as well.

Kubernetes イングレス コントローラー により、Kubernetes クラスター内のサービスへの HTTP(S) ルートが公開されます。Kubernetes Ingress Controller exposes HTTP(S) routes to services in a Kubernetes cluster. この目的には、Nginx または任意の適切なイングレス コントローラーを使用できます。Nginx or any suitable ingress controller can be used for this purpose.

Helm は、Kubernetes デプロイ用のパッケージ マネージャーであり、デプロイ、サービス、シークレットなどのさまざまな Kubernetes オブジェクトを 1 つの "チャート" にバンドルする手段を提供します。Helm is a package manager for Kubernetes deployment, providing a way to bundle different Kubernetes objects like Deployments, Services, Secrets, into a single "chart". チャート オブジェクトの発行、デプロイ、制御バージョン管理、および更新を行うことができます。You can publish, deploy, control version management, and update a chart object. Azure Container Registry は、パッケージ化された Helm チャートを格納するためのリポジトリとして使用できます。Azure Container Registry can be used as a repository to store packaged Helm Charts.

設計上の考慮事項Design considerations

このパターンは、この記事の次以降のセクションで詳しく説明されているいくつかの高レベルの考慮事項に従います。This pattern follows a few high-level considerations explained in more detail in the next sections of this article:

  • アプリケーションでは、ベンダー ロックインを避けるために、Kubernetes ネイティブ ソリューションを使用します。The application uses Kubernetes-native solutions, to avoid vendor lock-in.
  • アプリケーションではマイクロサービス アーキテクチャが使用されます。The application uses a microservices architecture.
  • Azure Stack Hub では受信は必要ありませんが、送信インターネット接続が許可されます。Azure Stack Hub doesn't need inbound but allows outbound Internet connectivity.

これらの推奨プラクティスは、実際のワークロードとシナリオにも適用されます。These recommended practices will apply to real-world workloads and scenarios as well.

スケーラビリティに関する考慮事項Scalability considerations

スケーラビリティは、一貫性があり信頼性とパフォーマンスの高いアプリケーションへのアクセスをユーザーに提供するために重要です。Scalability is important to provide users consistent, reliable, and well-performing access to the application.

サンプル シナリオでは、複数レイヤーのアプリケーション スタックのスケーラビリティについて説明します。The sample scenario covers scalability on multiple layers of the application stack. さまざまなレイヤーの概要を次に示します。Here's a high-level overview of the different layers:

アーキテクチャ レベルArchitecture level 影響Affects 方法はありますか。How?
ApplicationApplication ApplicationApplication ポッド、レプリカ、コンテナー インスタンスの数に基づく水平スケーリング*Horizontal scaling based on the number of Pods/Replicas/Container Instances*
クラスターCluster Kubernetes クラスターKubernetes cluster ノード数 (1 から 50)、VM-SKU サイズ、およびノード プール (Azure Stack Hub 上の AKS エンジンは、現在 1 つのノード プールのみをサポート)。AKS エンジンの scale コマンドを使用 (手動)Number of Nodes (between 1 and 50), VM-SKU-sizes, and Node Pools (AKS Engine on Azure Stack Hub currently supports only a single node pool); using AKS Engine's scale command (manual)
インフラストラクチャInfrastructure Azure Stack HubAzure Stack Hub Azure Stack Hub デプロイ内のノード数、容量、およびスケール ユニット数Number of nodes, capacity, and scale units within an Azure Stack Hub deployment

* Kubernetes の ポッドの水平オートスケーラー (HPA) を使用。コンテナー インスタンス (CPU やメモリ) のサイズ変更による、自動化されたメトリックベースのスケーリングまたは垂直スケーリング。* Using Kubernetes' Horizontal Pod Autoscaler (HPA); automated metric-based scaling or vertical scaling by sizing the container instances (cpu/memory).

Azure Stack Hub (インフラストラクチャ レベル)Azure Stack Hub (infrastructure level)

Azure Stack Hub はデータセンター内の物理ハードウェア上で実行されるため、Azure Stack Hub インフラストラクチャはこの実装の基盤です。The Azure Stack Hub infrastructure is the foundation of this implementation, because Azure Stack Hub runs on physical hardware in a datacenter. ハブ ハードウェアを選択するときは、CPU、メモリ密度、ストレージ構成、およびサーバー数を選択する必要があります。When selecting your Hub hardware, you need to make choices for CPU, memory density, storage configuration, and number of servers. Azure Stack Hub のスケーラビリティの詳細については、次のリソースをご確認ください。To learn more about Azure Stack Hub's scalability, check out the following resources:

Kubernetes クラスター (クラスター レベル)Kubernetes cluster (cluster level)

Kubernetes クラスター自体は、コンピューティング、ストレージ、ネットワーク リソースなどの Azure (Stack) IaaS コンポーネントで構成され、それらの上に構築されています。The Kubernetes cluster itself consists of, and is built on top of Azure (Stack) IaaS components including compute, storage, and network resources. Kubernetes ソリューションには、Azure (および Azure Stack Hub) 内に VM としてデプロイされるマスターおよびワーカー ノードが含まれます。Kubernetes solutions involve master and worker nodes, which are deployed as VMs in Azure (and Azure Stack Hub).

  • コントロール プレーン (マスター) により、主要な Kubernetes サービスと、アプリケーション ワークロードのオーケストレーションが提供されます。Control plane nodes (master) provide the core Kubernetes services and orchestration of application workloads.
  • ワーカー ノード (ワーカー) により、アプリケーション ワークロードが実行されます。Worker nodes (worker) run your application workloads.

初期デプロイの VM サイズを選択する際には、いくつかの考慮事項があります。When selecting VM sizes for the initial deployment, there are several considerations:

  • コスト - ワーカー ノードを計画するときは、発生する VM ごとのコスト全体を念頭に置いてください。Cost - When planning your worker nodes, keep in mind the overall cost per VM you'll incur. たとえば、アプリケーションのワークロードに限られたリソースが必要な場合は、サイズの小さい VM をデプロイすることを計画する必要があります。For example, if your application workloads require limited resources, you should plan to deploy smaller sized VMs. Azure のような Azure Stack Hub は通常、消費量に基づいて課金されるため、Kubernetes ロール用に VM を適切にサイズ設定することは、消費コストを最適化するために重要です。Azure Stack Hub, like Azure, is normally billed on a consumption basis, so appropriately sizing the VMs for Kubernetes roles is crucial to optimizing consumption costs.

  • スケーラビリティ - マスターおよびワーカー ノードの数をスケールインおよびアウトしたり、追加のノード プールを追加したりすることによって (現在、Azure Stack Hub 上では利用できません)、クラスターのスケーラビリティが実現されます。Scalability - Scalability of the cluster is achieved by scaling in and out the number of master and worker nodes, or by adding additional node pools (not available on Azure Stack Hub today). クラスターのスケーリングは、Container Insights (Azure Monitor + Log Analytics) を使用して収集されたパフォーマンス データに基づいて行うことができます。Scaling the cluster can be done based on performance data, collected using Container Insights (Azure Monitor + Log Analytics).

    アプリケーションに必要なリソースが増減する場合は、現在のノードを水平方向 (1 から 50 ノード) にスケールアウト (またはイン) できます。If your application needs more (or fewer) resources, you can scale out (or in) your current nodes horizontally (between 1 and 50 nodes). 50 を超えるノードが必要な場合は、別のサブスクリプション内で追加のクラスターを作成できます。If you need more than 50 nodes, you can create an additional cluster in a separate subscription. クラスターを再デプロイしないと、実際の VM を別の VM サイズに垂直方向にスケールアップすることはできません。You can't scale up the actual VMs vertically to another VM size without redeploying the cluster.

    スケーリングは、最初に Kubernetes クラスターをデプロイするために使用された AKS エンジン ヘルパー VM を使用して手動で行います。Scaling is done manually using the AKS Engine helper VM that was used to deploy the Kubernetes cluster initially. 詳細については、「Kubernetes クラスターのスケーリング」を参照してくださいFor more information, see Scaling Kubernetes clusters

  • クォータ - Azure Stack Hub 上で AKS のデプロイを計画するときに構成したクォータについて検討します。Quotas - Consider the quotas you've configured when planning out an AKS deployment on your Azure Stack Hub. サブスクリプションに適切なプランとクォータが構成されていることを確認します。Make sure each subscription has the proper plans and the quotas configured. サブスクリプションは、スケールアウトの際にクラスターに必要なコンピューティング、ストレージ、およびその他のサービスの量に対応できる必要があります。The subscription will need to accommodate the amount of compute, storage, and other services needed for your clusters as they scale out.

  • アプリケーションのワークロード - Azure Kubernetes Service ドキュメントの Kubernetes コア概念に関する記事でクラスターとワークロードの概念に関するページをご覧ください。Application workloads - Refer to the Clusters and workloads concepts in the Kubernetes core concepts for Azure Kubernetes Service document. この記事は、アプリケーションのコンピューティングとメモリのニーズに基づいて適切な VM サイズを調べるのに役立ちます。This article will help you scope the proper VM size based on the compute and memory needs of your application.

アプリケーション (アプリケーション レベル)Application (application level)

アプリケーション レイヤーでは、Kubernetes のポッドの水平オートスケーラー (HPA) を使用します。On the application layer, we use Kubernetes Horizontal Pod Autoscaler (HPA). HPA を使用して、さまざまなメトリック (CPU 使用率など) に基づいて、デプロイ内のレプリカ (ポッドとコンテナー インスタンス) の数を増減できます。HPA can increase or decrease the number of Replicas (Pod/Container Instances) in our deployment based on different metrics (like CPU utilization).

別の方法として、コンテナー インスタンスを垂直方向にスケーリングすることもできます。Another option is to scale container instances vertically. これは、特定のデプロイで要求され、使用できる CPU とメモリの量を変更することによって実現できます。This can be accomplished by changing the amount of CPU and Memory requested and available for a specific deployment. 詳細については、kubernetes.io で「コンテナーのリソース管理」を参照してください。See Managing Resources for Containers on kubernetes.io to learn more.

ネットワークと接続性に関する考慮事項Networking and connectivity considerations

ネットワークと接続は、Azure Stack Hub 上の Kubernetes について前述した 3 つのレイヤーにも影響します。Networking and connectivity also affect the three layers mentioned previously for Kubernetes on Azure Stack Hub. 次の表は、レイヤーとそれらに含まれるサービスを示しています。The following table shows the layers and which services they contain:

レイヤーLayer 影響Affects 何ですか?What?
ApplicationApplication ApplicationApplication アプリケーションにアクセスする方法。How is the application accessible? インターネットに公開されるかどうか。Will it be exposed to the Internet?
クラスターCluster Kubernetes クラスターKubernetes cluster Kubernetes API、AKS エンジン VM、コンテナー イメージのプル (エグレス)、監視データとテレメトリの送信 (エグレス)Kubernetes API, AKS Engine VM, Pulling container images (egress), Sending monitoring data and telemetry (egress)
インフラストラクチャInfrastructure Azure Stack HubAzure Stack Hub ポータルや Azure Resource Manager エンドポイントなどの Azure Stack Hub 管理エンドポイントのアクセシビリティ。Accessibility of the Azure Stack Hub management endpoints like the portal and Azure Resource Manager endpoints.

アプリケーションApplication

アプリケーション レイヤーの場合、最も重要な考慮事項は、アプリケーションが公開され、インターネットからアクセス可能であるかどうかです。For the application layer, the most important consideration is whether the application is exposed and accessible from the Internet. Kubernetes の観点から見ると、インターネット アクセシビリティとは、Kubernetes サービスまたはイングレス コントローラーを使用してデプロイまたはポッドを公開することを意味します。From a Kubernetes perspective, Internet accessibility means exposing a deployment or pod using a Kubernetes Service or an Ingress Controller.

注意

Azure Stack Hub 上のフロントエンド パブリック IP の数は 5 つに制限されているため、イングレス コントローラーを使用して Kubernetes サービスを公開することをお勧めします。We recommend the use of Ingress controllers to expose Kubernetes Services as the number of Frontend public IPs on Azure Stack Hub is limited to 5. この設計では、(LoadBalancer タイプの) Kubernetes サービスの数も 5 つに制限されます。これは、多くのデプロイに対して小さすぎます。This design also limits the number of Kubernetes Services (with the type LoadBalancer) to 5, which will be too small for many deployments. 詳細については、AKS エンジンのドキュメントをご覧ください。Go to the AKS Engine documentation to learn more.

ロード バランサーまたはイングレス コントローラーを介してパブリック IP を使用してアプリケーションを公開することは、アプリケーションがインターネット経由でアクセスできるようになったことを意味するものではありません。Exposing an application using a public IP via a Load Balancer or an Ingress Controller doesn't nessecarily mean that the application is now accessible via the Internet. Azure Stack Hub は、ローカル イントラネット上でのみ見えるパブリック IP アドレスを持つことができます。すべてのパブリック IP アドレスが実際にインターネットに接続されているわけではありません。It's possible for Azure Stack Hub to have a public IP address that is only visible on the local intranet - not all public IPs are truly Internet-facing.

前のブロックでは、アプリケーションへのイングレス トラフィックを考慮しています。The previous block considers ingress traffic to the application. Kubernetes のデプロイを成功させるために考慮する必要があるもう 1 つのトピックは、送信およびエグレス トラフィックです。Another topic that must be considered for a successful Kubernetes deployment is outbound/egress traffic. エグレス トラフィックを必要とするいくつかのユース ケースを次に示します。Here are a few use cases that require egress traffic:

  • DockerHub または Azure Container Registry に格納されているコンテナー イメージのプルPulling Container Images stored on DockerHub or Azure Container Registry
  • Helm チャートの取得Retrieving Helm Charts
  • Application Insights データ (またはその他の監視データ) の出力Emitting Application Insights data (or other monitoring data)

一部のエンタープライズ環境では "透過的" または "非透過的" プロキシ サーバーの使用が必要になる場合があります。Some enterprise environments might require the use of transparent or non-transparent proxy servers. これらのサーバーには、クラスターのさまざまなコンポーネントに対する特定の構成が必要です。These servers require specific configuration on various components of our cluster. AKS エンジンのドキュメントには、ネットワーク プロキシに対応する方法についてのさまざまな詳細が記載されています。The AKS Engine documentation contains various details on how to accommodate network proxies. 詳細については、「AKS エンジンとプロキシ サーバー」を参照してくださいFor more details, see AKS Engine and proxy servers

最後に、クラスター間のトラフィックは、Azure Stack Hub インスタンス間を流れる必要があります。Lastly, cross-cluster traffic must flow between Azure Stack Hub instances. サンプルのデプロイは、個々の Azure Stack Hub インスタンス上で実行されている個々の Kubernetes クラスターで構成されます。The sample deployment consists of individual Kubernetes clusters running on individual Azure Stack Hub instances. 2 つのデータベース間のレプリケーション トラフィックなど、これらの間のトラフィックは "外部トラフィック" です。Traffic between them, such as the replication traffic between two databases, is "external traffic". 外部トラフィックは、2 つの Azure Stack Hub インスタンス上で Kubernetes を接続するために、サイト間 VPN または Azure Stack Hub のパブリック IP アドレスを通じてルーティングする必要があります。External traffic must be routed through either a Site-to-Site VPN or Azure Stack Hub Public IP addresses to connect Kubernetes on two Azure Stack Hub instances:

クラスター間または内トラフィック

クラスターCluster

Kubernetes クラスターには、必ずしもインターネット経由でアクセスできる必要はありません。The Kubernetes cluster doesn't necessarily need to be accessible via the Internet. 関連する部分は、たとえば kubectl を使用したクラスターの操作に使用される Kubernetes API です。The relevant part is the Kubernetes API used to operate a cluster, for example, using kubectl. Kubernetes API エンドポイントは、クラスターを操作するすべてのユーザーからアクセスできるようにするか、アプリケーションとサービスをその上にデプロイする必要があります。The Kubernetes API endpoint must be accessible to everyone who operates the cluster or deploys applications and services on top of it. このトピックの詳細については、下の「デプロイ (CI/CD) に関する考慮事項」で DevOps の観点から見た詳細をご覧ください。This topic is covered in more detail from a DevOps-perspective in the Deployment (CI/CD) considerations section below.

クラスター レベルでは、エグレス トラフィックに関する考慮事項もいくつかあります。On the cluster level, there are also a few considerations around egress-traffic:

  • ノードの更新 (Ubuntu の場合)Node updates (for Ubuntu)
  • (Azure LogAnalytics に送信された) データの監視Monitoring data (sent to Azure LogAnalytics)
  • 送信トラフィックを必要とする他のエージェント (各デプロイ担当者の環境に固有)Other agents requiring outbound traffic (specific to each deployer's environment)

AKS エンジンを使用して Kubernetes クラスターをデプロイする前に、最終的なネットワーク設計を計画してください。Before you deploy your Kubernetes cluster using AKS Engine, plan for the final networking design. 専用の仮想ネットワークを作成するのではなく、既存のネットワークにクラスターをデプロイする方が効率的な場合があります。Instead of creating a dedicated Virtual Network, it may be more efficient to deploy a cluster into an existing network. たとえば、Azure Stack Hub 環境で既に構成されている既存のサイト間 VPN 接続を利用できます。For example, you might leverage an existing Site-to-Site VPN connection already configured in your Azure Stack Hub environment.

インフラストラクチャInfrastructure

インフラストラクチャとは、Azure Stack Hub 管理エンドポイントへのアクセスを指します。Infrastructure refers to accessing the Azure Stack Hub management endpoints. エンドポイントには、テナントと管理ポータル、および Azure Resource Manager 管理者とテナントのエンドポイントが含まれます。Endpoints include the tenant and admin portals, and the Azure Resource Manager admin and tenant endpoints. これらのエンドポイントは、Azure Stack Hub とそのコア サービスを操作するために必要です。These endpoints are required to operate Azure Stack Hub and its core services.

データとストレージに関する考慮事項Data and storage considerations

2 つの Azure Stack Hub インスタンスにまたがって、2 つの個別の Kubernetes クラスターにアプリケーションの 2 つのインスタンスがデプロイされます。Two instances of our application will be deployed, on two individual Kubernetes clusters, across two Azure Stack Hub instances. この設計の場合、データをレプリケートしてそれらの間で同期する方法を検討する必要があります。This design will require us to consider how to replicate and synchronize data between them.

Azure では、クラウド内の複数のリージョンとゾーンにわたってストレージをレプリケートする機能が組み込まれています。With Azure, we have the built-in capability to replicate storage across multiple regions and zones within the cloud. 現在 Azure Stack Hub には、2つの異なる Azure Stack Hub インスタンスにストレージをレプリケートするネイティブな方法はありません。2 つの独立したクラウドが形成され、それらをセットとして管理するための包括的な方法はありません。Currently with Azure Stack Hub there are no native ways to replicate storage across two different Azure Stack Hub instances - they form two independent clouds with no overarching way to manage them as a set. Azure Stack Hub で実行されているアプリケーションの回復性を計画すると、アプリケーションの設計とデプロイにおいて、このような独立性を考慮せざるを得なくなります。Planning for resiliency of applications running across Azure Stack Hub forces you to consider this independence in your application design and deployments.

ほとんどの場合、AKS にデプロイされた回復力のある高可用性アプリケーションにはストレージのレプリケーションは必要ありません。In most cases, storage replication won't be necessary for a resilient and highly available application deployed on AKS. ただし、アプリケーションの設計では、Azure Stack Hub インスタンスごとに個別のストレージを考慮する必要があります。But you should consider independent storage per Azure Stack Hub instance in your application design. この設計が Azure Stack Hub へのソリューションのデプロイに対する懸念事項または障害である場合、ストレージの添付を提供する Microsoft パートナーのソリューションがあります。If this design is a concern or road block to deploying the solution on Azure Stack Hub, there are possible solutions from Microsoft Partners that provide storage attachments. ストレージの添付により、複数の Azure Stack Hub と Azure 間にストレージ レプリケーション ソリューションが提供されます。Storage attachments provide a storage replication solution across multiple Azure Stack Hubs and Azure. 詳細については、「パートナー ソリューション」を参照してください。For more information, see the Partner solutions.

このアーキテクチャでは、以下のレイヤーを検討しました。In our architecture, these layers were considered:

ConfigurationConfiguration

構成には、Azure Stack Hub、AKS エンジン、および Kubernetes クラスター自体の構成が含まれます。Configuration includes the configuration of Azure Stack Hub, AKS Engine, and the Kubernetes cluster itself. 構成は、可能な限り自動化し、Azure DevOps や GitHub などの Git ベースのバージョン コントロール システムにコードとしてのインフラストラクチャとして格納する必要があります。The configuration should be automated as much as possible, and stored as Infrastructure-as-Code in a Git-based version control system like Azure DevOps or GitHub. これらの設定を複数のデプロイ間で簡単に同期することはできません。These settings cannot easily be synchronized across multiple deployments. そのため、構成を外部から保存および適用し、DevOps パイプラインを使用することをお勧めします。Therefore we recommend storing and applying configuration from the outside, and using DevOps pipeline.

アプリケーションApplication

アプリケーションは、Git ベースのリポジトリに格納する必要があります。The application should be stored in a Git-based repository. 新しいデプロイがある場合、アプリケーションに変更を加えた場合、またはディザスター リカバリーを行う場合は、Azure Pipelines を使用して簡単にデプロイできます。Whenever there's a new deployment, changes to the application, or disaster recovery, it can be easily deployed using Azure Pipelines.

データData

データは、ほとんどのアプリケーション設計で最も重要な考慮事項です。Data is the most important consideration in most application designs. アプリケーション データは、アプリケーションの異なるインスタンス間で同期されている必要があります。Application data must stay in sync between the different instances of the application. また、障害が発生した場合に備えて、データのバックアップとディザスター リカバリーの戦略も必要です。Data also needs a backup and disaster recovery strategy if there's an outage.

この設計の実現は、テクノロジの選択に大きく依存します。Achieving this design depends heavily on technology choices. Azure Stack Hub 上で可用性の高い方法でデータベースを実装するためのソリューション例を次に示します。Here are some solution examples for implementing a database in a highly available fashion on Azure Stack Hub:

複数の場所でデータを操作する場合の考慮事項は、可用性と回復性が高いソリューションではさらに複雑な考慮事項です。Considerations when working with data across multiple locations is an even more complex consideration for a highly available and resilient solution. 次の点を考慮してください。Consider:

  • Azure Stack Hub 間の待機時間とネットワーク接続。Latency and network connectivity between Azure Stack Hubs.
  • サービスとアクセス許可のための ID の可用性。Availability of identities for services and permissions. 各 Azure Stack Hub インスタンスは、外部ディレクトリと統合されます。Each Azure Stack Hub instance integrates with an external directory. デプロイ時に、Azure Active Directory (Azure AD) または Active Directory フェデレーション サービス (ADFS) のどちらを使用するかを選択します。During deployment, you choose to use either Azure Active Directory (Azure AD) or Active Directory Federation Services (ADFS). そのため、複数の独立した Azure Stack Hub インスタンスと対話できる 1 つの ID を使用する可能性があります。As such, there's potential to use a single identity that can interact with multiple independent Azure Stack Hub instances.

事業継続とディザスター リカバリーBusiness continuity and disaster recovery

事業継続とディザスター リカバリー (BCDR) は、Azure Stack Hub と Azure の両方で重要なトピックです。Business continuity and disaster recovery (BCDR) is an important topic in both Azure Stack Hub and Azure. 主な違いは、Azure Stack Hub ではオペレーターが BCDR プロセス全体を管理する必要があることです。The main difference is that in Azure Stack Hub, the operator must manage the whole BCDR process. Azure では、BCDR の一部が Microsoft によって自動的に管理されます。In Azure, parts of BCDR are automatically managed by Microsoft.

BCDR は、前のセクション「データとストレージに関する考慮事項」で説明したのと同じ領域に影響を与えます。BCDR affects the same areas mentioned in the previous section Data and storage considerations:

  • インフラストラクチャと構成Infrastructure / Configuration
  • アプリケーションの可用性Application Availability
  • アプリケーション データApplication Data

前のセクションで説明したように、これらの領域は Azure Stack Hub オペレーターの担当であり、組織によって異なる場合があります。And as mentioned in the previous section, these areas are the responsibility of the Azure Stack Hub operator and can vary between organizations. 使用可能なツールとプロセスに従って BCDR を計画します。Plan BCDR according to your available tools and processes.

インフラストラクチャと構成Infrastructure and configuration

このセクションでは、Azure Stack Hub の物理的および論理的なインフラストラクチャと構成について説明します。This section covers the physical and logical infrastructure and the configuration of Azure Stack Hub. 管理およびテナント スペースでの操作について説明します。It covers actions in the admin and the tenant spaces.

Azure Stack Hub オペレーター (または管理者) は、Azure Stack Hub インスタンスのメンテナンスを担当します。The Azure Stack Hub operator (or administrator) is responsible for maintenance of the Azure Stack Hub instances. ネットワーク、ストレージ、ID などのコンポーネントと、この記事の範囲外のその他のトピックが含まれます。Including components such as the network, storage, identity, and other topics that are outside the scope of this article. Azure Stack Hub の操作の詳細については、次のリソースをご覧ください。To learn more about the specifics of Azure Stack Hub operations, see the following resources:

Azure Stack Hub は、Kubernetes アプリケーションがデプロイされるプラットフォームでありファブリックです。Azure Stack Hub is the platform and fabric on which Kubernetes applications will be deployed. Kubernetes アプリケーションのアプリケーション所有者は Azure Stack Hub のユーザーになり、ソリューションに必要なアプリケーション インフラストラクチャをデプロイするためのアクセス権が付与されます。The application owner for the Kubernetes application will be a user of Azure Stack Hub, with access granted to deploy the application infrastructure needed for the solution. この場合のアプリケーション インフラストラクチャは、AKS エンジンを使用してデプロイされた Kubernetes クラスターと、その周辺のサービスを意味します。Application infrastructure in this case means the Kubernetes cluster, deployed using AKS Engine, and the surrounding services. これらのコンポーネントは Azure Stack Hub にデプロイされ、Azure Stack Hub オファーによって制約されます。These components will be deployed into Azure Stack Hub, constrained by an Azure Stack Hub offer. Kubernetes アプリケーション所有者が受け入れるオファーに、ソリューション全体をデプロイするのに十分な容量 (Azure Stack Hub クォータで表される) があることを確認します。Make sure the offer accepted by the Kubernetes application owner has sufficient capacity (expressed in Azure Stack Hub quotas) to deploy the entire solution. 前のセクションで推奨されているように、アプリケーションのデプロイは、コードとしてのインフラストラクチャと、Azure DevOps Azure Pipelines のようなデプロイ パイプラインを使用して自動化する必要があります。As recommended in the previous section, the application deployment should be automated using Infrastructure-as-Code and deployment pipelines like Azure DevOps Azure Pipelines.

Azure Stack Hub の詳細については、「Azure Stack Hub サービス、プラン、オファー、サブスクリプションの概要」を参照してくださいFor more information on Azure Stack Hub offers and quotas, see Azure Stack Hub services, plans, offers, and subscriptions overview

AKS エンジンの構成は、その出力を含めて安全に保存し、格納することが重要です。It's important to securely save and store the AKS Engine configuration including its outputs. これらのファイルには、Kubernetes クラスターへのアクセスに使用される機密情報が含まれているため、管理者以外に公開されないように保護する必要があります。These files contain confidential information used to access the Kubernetes cluster, so it must be protected from being exposed to non-administrators.

アプリケーションの可用性Application availability

デプロイされたインスタンスのバックアップにアプリケーションが依存しないようにしてください。The application shouldn't rely on backups of a deployed instance. 標準的な方法としては、コードとしてのインフラストラクチャ パターンに従ってアプリケーションを完全に再デプロイします。As a standard practice, redeploy the application completely following Infrastructure-as-Code patterns. たとえば、Azure DevOps Azure Pipelines を使用して再デプロイします。For example, redeploy using Azure DevOps Azure Pipelines. BCDR プロシージャでは、同じまたは別の Kubernetes クラスターにアプリケーションを再デプロイする必要があります。The BCDR procedure should involve the redeployment of the application to the same or another Kubernetes cluster.

アプリケーション データApplication data

アプリケーション データは、データの損失を最小限に抑えるための重要な部分です。Application data is the critical part to minimize data loss. 前のセクションでは、アプリケーションの 2 つ (またはそれ以上) のインスタンス間でデータをレプリケートおよび同期する手法について説明しました。In the previous section, techniques to replicate and synchronize data between two (or more) instances of the application were described. データの格納に使用されるデータベース インフラストラクチャ (MySQL、MongoDB、MSSQL など) によっては、さまざまなデータベース可用性とバックアップの手法から選択できます。Depending on the database infrastructure (MySQL, MongoDB, MSSQL or others) used to store the data, there will be different database availability and backup techniques available to choose from.

整合性を確保するには、次のいずれかの方法を使用することをお勧めします。The recommended ways to achieve integrity are to use either:

  • 特定のデータベースのネイティブ バックアップ ソリューション。A native backup solution for the specific database.
  • アプリケーションで使用されるデータベースの種類のバックアップと回復を正式にサポートするバックアップ ソリューション。A backup solution that officially supports backup and recovery of the database type used by your application.

重要

アプリケーション データが存在するのと同じ Azure Stack Hub インスタンスにバックアップ データを格納しないでください。Do not store your backup data on the same Azure Stack Hub instance where your application data resides. Azure Stack Hub インスタンスが完全に停止すると、バックアップも危険にさらされます。A complete outage of the Azure Stack Hub instance would also compromise your backups.

可用性に関する考慮事項Availability considerations

AKS エンジンを介してデプロイされた Azure Stack Hub 上の Kubernetes は、マネージド サービスではありません。Kubernetes on Azure Stack Hub deployed via AKS Engine isn't a managed service. これは、Azure サービスとしてのインフラストラクチャ (IaaS) を使用した Kubernetes クラスターの自動化されたデプロイと構成です。It's an automated deployment and configuration of a Kubernetes cluster using Azure Infrastructure-as-a-Service (IaaS). そのため、基になるインフラストラクチャと同じ可用性を提供します。As such, it provides the same availability as the underlying infrastructure.

Azure Stack Hub インフラストラクチャは、既に障害に対する回復性があり、複数の障害および更新ドメインにコンポーネントを分散する可用性セットのような機能を提供します。Azure Stack Hub infrastructure is already resilient to failures, and provides capabilities like Availability Sets to distribute components across multiple fault and update domains. しかし、基盤となっているテクノロジ (フェールオーバー クラスタリング) では、ハードウェアが故障した場合にその影響を受ける物理サーバー上の VM に多少のダウンタイムが発生します。But the underlying technology (failover clustering) still incurs some downtime for VMs on an impacted physical server, if there's a hardware failure.

運用環境の Kubernetes クラスターに加えて、ワークロードを 2 つ (またはそれ以上) のクラスターにデプロイすることをお勧めします。It's a good practice to deploy your production Kubernetes cluster as well as the workload to two (or more) clusters. これらのクラスターは別の場所またはデータセンターにホストする必要があり、Azure Traffic Manager などのテクノロジを使用して、クラスターの応答時間に基づくか地理に基づいてユーザーをルーティングします。These clusters should be hosted in different locations or datacenters, and use technologies like Azure Traffic Manager to route users based on cluster response time or based on geography.

Traffic Manager を使用したトラフィック フローの制御

1 つだけの Kubernetes クラスターを持つお客様は、通常、特定のアプリケーションのサービス IP または DNS 名に接続します。Customers who have a single Kubernetes cluster typically connect to the service IP or DNS name of a given application. 複数クラスターのデプロイでは、各 Kubernetes クラスター上のサービスとイングレスを指す、Traffic Manager DNS 名に接続するようにしましょう。In a multi-cluster deployment, customers should connect to a Traffic Manager DNS name that points to the services/ingress on each Kubernetes cluster.

Traffic Manager を使用したオンプレミス クラスターへのルーティング

AKS エンジンを介してデプロイされる Kubernetes クラスター自体は、少なくとも 3 つのマスター ノードと 2 つのワーカー ノードで構成されている必要があります。The Kubernetes cluster itself, deployed via AKS Engine, should consist of at least three master nodes and two worker nodes.

ID とセキュリティに関する考慮事項Identity and security considerations

ID とセキュリティは重要なトピックです。Identity and security are important topics. ソリューションが独立した Azure Stack Hub インスタンスにまたがっている場合は特にそうです。Especially when the solution spans independent Azure Stack Hub instances. Kubernetes と Azure (Azure Stack Hub を含む) のどちらにも、ロールベースのアクセス制御 (RBAC) について固有のメカニズムがあります。Kubernetes and Azure (including Azure Stack Hub) both have distinct mechanisms for role-based access control (RBAC):

  • Azure RBAC により、Azure (および Azure Stack Hub) でのリソースへのアクセス (新しい Azure リソースを作成する機能を含む) が制御されます。Azure RBAC controls access to resources in Azure (and Azure Stack Hub), including the ability to create new Azure resources. アクセス許可は、ユーザー、グループ、またはサービス プリンシパルに割り当てることができます。Permissions can be assigned to users, groups, or service principals. (サービス プリンシパルは、アプリケーションによって使用されるセキュリティ ID です。)(A service principal is a security identity used by applications.)
  • Kubernetes RBAC は、Kubernetes API へのアクセス許可を制御します。Kubernetes RBAC controls permissions to the Kubernetes API. たとえば、ポッドの作成やポッドの一覧表示は、RBAC によってユーザーに許可 (または拒否) できるアクションです。For example, creating pods and listing pods are actions that can be authorized (or denied) to a user through RBAC. ユーザーに Kubernetes アクセス許可を割り当てるには、ロールとロール バインディングを作成します。To assign Kubernetes permissions to users, you create roles and role bindings.

Azure Stack Hub ID と RBACAzure Stack Hub identity and RBAC

Azure Stack Hub では、ID プロバイダーに 2 つの選択肢が用意されています。Azure Stack Hub provides two identity provider choices. 使用するプロバイダーは、環境と、接続されている、または切断されている環境のどちらで実行するかによって決まります。The provider you use depends on the environment and whether running in a connected or disconnected environment:

  • Azure AD - 接続された環境でのみ使用できます。Azure AD - can only be used in a connected environment.
  • 従来の Active Directory フォレストへの ADFS - 接続されている、または切断されている環境のどちらでも使用できます。ADFS to a traditional Active Directory forest - can be used in both a connected or disconnected environment.

ID プロバイダーにより、ユーザーとグループが管理されます。これには、リソースにアクセスするための認証と認可が含まれます。The identity provider manages users and groups, including authentication and authorization for accessing resources. サブスクリプション、リソース グループ、VM やロード バランサーなどの個々のリソースのような Azure Stack Hub リソースへのアクセス権を付与することができます。Access can be granted to Azure Stack Hub resources like subscriptions, resource groups, and individual resources like VMs or load balancers. 一貫性のあるアクセス モデルを使用するには、すべての Azure Stack Hub に同じグループ (直接または入れ子) を使用することを検討する必要があります。To have a consistent access model, you should consider using the same groups (either direct or nested) for all Azure Stack Hubs. 次に構成例を示します。Here's a configuration example:

azure stack hub を使用した入れ子になった aad グループ

この例には、特定の目的を持つ専用のグループ (AAD または ADFS を使用) が含まれています。The example contains a dedicated group (using AAD or ADFS) for a specific purpose. たとえば、特定の Azure Stack Hub インスタンス (ここでは、"Seattle K8s Cluster Contributor") に Kubernetes クラスター インフラストラクチャを含むリソース グループに対する共同作成者のアクセス許可を付与します。For example, to provide Contributor permissions for the Resource Group that contains our Kubernetes cluster infrastructure on a specific Azure Stack Hub instance (here "Seattle K8s Cluster Contributor"). これらのグループは、各 Azure Stack Hub の "サブグループ" を含む全体グループに入れ子になっています。These groups are then nested into an overall group that contains the "subgroups" for each Azure Stack Hub.

サンプル ユーザーには、Kubernetes インフラストラクチャ リソースのセット全体を含む両方のリソース グループに対する "共同作成者" アクセス許可が付与されました。Our sample user will now have "Contributor" permissions to both Resources Groups that contain the entire set of Kubernetes infrastructure resources. インスタンスは同じ ID プロバイダーを共有するので、ユーザーは両方の Azure Stack Hub インスタンス上のリソースにアクセスできます。The user will have access to resources on both Azure Stack Hub instances, because the instances share the same identity provider.

重要

これらのアクセス許可は、Azure Stack Hub と、その上にデプロイされた一部のリソースにのみ影響します。These permissions affect only Azure Stack Hub and some of the resources deployed on top of it. このレベルのアクセス権を持つユーザーは、多くの問題を引き起こすことがありますが、Kubernetes デプロイに追加でアクセスすることなく Kubernetes IaaS VM や Kubernetes API にアクセスすることはできません。A user who has this level of access can do a lot of harm, but cannot access the Kubernetes IaaS VMs nor the Kubernetes API without additional access to the Kubernetes deployment.

Kubernetes ID と RBACKubernetes identity and RBAC

既定では、Kubernetes クラスターは、基盤となる Azure Stack Hub と同じ ID プロバイダーを使用しません。A Kubernetes cluster, by default, doesn't use the same Identity Provider as the underlaying Azure Stack Hub. Kubernetes クラスター、マスター、およびワーカー ノードをホストしている VM は、クラスターのデプロイ時に指定された SSH キーを使用します。The VMs hosting the Kubernetes cluster, the master, and worker nodes, use the SSH Key that is specified during the deployment of the cluster. この SSH キーは、SSH を使用してこれらのノードに接続するために必要です。This SSH key is required to connect to these nodes using SSH.

Kubernetes API (たとえば、kubectl を使用してアクセスされる) は、既定の "cluster admin" サービス アカウントを含むサービス アカウントによっても保護されます。The Kubernetes API (for example, accessed by using kubectl) is also protected by service accounts including a default "cluster admin" service account. このサービス アカウントの資格情報は、最初は Kubernetes マスター ノード上の .kube/config ファイルに格納されています。The credentials for this service account are initially stored in the .kube/config file on your Kubernetes master nodes.

シークレットの管理とアプリケーションの資格情報Secrets management and application credentials

接続文字列やデータベース資格情報などのシークレットを格納するには、次のようないくつかの選択肢があります。To store secrets like connection strings or database credentials there are several choices, including:

  • Azure Key VaultAzure Key Vault
  • Kubernetes シークレットKubernetes Secrets
  • HashiCorp Vault のようなサードパーティ ソリューション (Kubernetes 上で実行)3rd-Party solutions like HashiCorp Vault (running on Kubernetes)

構成ファイル、アプリケーション コード、またはスクリプト内にシークレットや資格情報をプレーンテキストで保存しないでください。Do not store secrets or credentials in plaintext in your configuration files, application code, or within scripts. また、バージョン コントロール システムには格納しないでください。And do not store them in a version control system. 代わりに、必要に応じてデプロイの自動化によってシークレットを取得する必要があります。Instead, the deployment automation should retrieve the secrets as needed.

パッチと更新プログラムPatch and update

Azure Kubernetes Service の パッチと更新プログラム (PNU) プロセスは、部分的に自動化されています。The Patch and Update (PNU) process in Azure Kubernetes Service is partially automated. Kubernetes バージョンのアップグレードは手動でトリガーされますが、セキュリティ更新プログラムは自動的に適用されます。Kubernetes version upgrades are triggered manually, while security updates are applied automatically. これらの更新プログラムには、OS のセキュリティ修正プログラムやカーネルの更新プログラムが含まれている場合があります。These updates can include OS security fixes or kernel updates. AKS は、更新プロセスを完了するためにこれらの Linux ノードを自動的に再起動しません。AKS doesn't automatically reboot these Linux nodes to complete the update process.

Azure Stack Hub 上で AKS エンジンを使用してデプロイされた Kubernetes クラスターの場合、PNU プロセスは管理されません。これは、クラスター オペレーターが担当します。The PNU process for a Kubernetes cluster deployed using AKS Engine on Azure Stack Hub is unmanaged, and is the responsibility of the cluster operator.

AKS エンジンは、2 つの最も重要なタスクに役立ちます。AKS Engine helps with the two most important tasks:

新しいベース OS イメージには、最新の OS セキュリティ修正プログラムとカーネル更新プログラムが含まれています。Newer base OS images contain the latest OS security fixes and kernel updates.

無人アップグレード メカニズムでは、新しいベース OS イメージ バージョンを Azure Stack Hub Marketplace で利用できるようになる前にリリースされたセキュリティ更新プログラムが自動的にインストールされます。The Unattended Upgrade mechanism automatically installs security updates that are released before a new base OS image version is available in the Azure Stack Hub Marketplace. 無人アップグレードは既定で有効になっており、セキュリティ更新プログラムは自動的にインストールされますが、Kubernetes クラスター ノードは再起動されません。Unattended upgrade is enabled by default and installs security updates automatically, but does not reboot the Kubernetes cluster nodes. ノードの再起動は、オープンソースの K Ubernetes RE boot D aemon (kured)) を使用して自動化できます。Rebooting the nodes can be automated using the open-source K Ubernetes RE boot D aemon (kured)). Kured によって、再起動を必要とする Linux ノードが監視され、ポッドの実行とノードの再起動プロセスの再スケジュールが自動的に処理されます。Kured watches for Linux nodes that require a reboot, then automatically handle the rescheduling of running pods and node reboot process.

デプロイ (CI/CD) に関する考慮事項Deployment (CI/CD) considerations

Azure と Azure Stack Hub では同じ Azure Resource Manager REST API が公開されます。Azure and Azure Stack Hub expose the same Azure Resource Manager REST APIs. これらの API は、他の Azure クラウド (Azure、Azure China 21Vianet、Azure Government) と同様に対処されます。These APIs are addressed like any other Azure cloud (Azure, Azure China 21Vianet, Azure Government). クラウド間の API バージョンに違いがある可能性があり、Azure Stack Hub ではサービスのサブセットのみが提供されます。There may be differences in API versions between clouds, and Azure Stack Hub provides only a subset of services. また、管理エンドポイントの URI は、クラウドごと、および Azure Stack Hub のインスタンスごとに異なります。The management endpoint URI is also different for each cloud, and each instance of Azure Stack Hub.

ここで説明した微妙な違いを除けば、Azure Resource Manager REST API によって、Azure と Azure Stack Hub の両方と対話するための一貫した方法が提供されます。Aside from the subtle differences mentioned, Azure Resource Manager REST APIs provide a consistent way to interact with both Azure and Azure Stack Hub. ここでは、他の Azure クラウドで使用したものと同じツール セットを使用できます。The same set of tools can be used here as would be used with any other Azure cloud. Azure DevOps、Jenkins などのツール、または PowerShell を使用して、サービスを Azure Stack Hub にデプロイし、オーケストレーションを行うことができます。You can use Azure DevOps, tools like Jenkins, or PowerShell, to deploy and orchestrate services to Azure Stack Hub.

考慮事項Considerations

Azure Stack Hub のデプロイに関する大きな違いの 1 つは、インターネット アクセシビリティの問題です。One of the major differences when it comes to Azure Stack Hub deployments is the question of Internet accessibility. インターネット アクセシビリティによって、CI/CD ジョブに対して、Microsoft ホステッドとセルフホステッド のどちらのビルド エージェントを選択するかが決まります。Internet accessibility determines whether to select a Microsoft-hosted or a self-hosted build agent for your CI/CD jobs.

セルフホステッド エージェントは、Azure Stack Hub の上で (IaaS VM として)、または Azure Stack Hub にアクセスできるネットワーク サブネット内で実行できます。A self-hosted agent can run on top of Azure Stack Hub (as an IaaS VM) or in a network subnet that can access Azure Stack Hub. 相違点の詳細については、「Azure Pipelines エージェント」をご覧ください。Go to Azure Pipelines agents to learn more about the differences.

次の図は、セルフホステッドまたは Microsoft ホステッドのどちらのビルド エージェントが必要かを判断するのに役立ちます。The following image helps you to decide if you need a self-hosted or a Microsoft-hosted build agent:

セルフホステッド ビルド エージェント。はいまたはいいえ

  • Azure Stack Hub 管理エンドポイントは、インターネット経由でアクセスできますか。Are the Azure Stack Hub management endpoints accessible via Internet?
    • はい:Microsoft ホステッド エージェントと共に Azure Pipelines を使用して、Azure Stack Hub に接続できます。Yes: We can use Azure Pipelines with Microsoft-hosted agents to connect to Azure Stack Hub.
    • いいえ:Azure Stack Hub の管理エンドポイントに接続できるセルフホステッド エージェントが必要です。No: We need self-hosted agents that can connect to Azure Stack Hub's management endpoints.
  • Kubernetes クラスターにはインターネット経由でアクセスできますか。Is our Kubernetes cluster accessible via the Internet?
    • はい:Microsoft ホステッド エージェントと共に Azure Pipelines を使用して、Kubernetes API エンドポイントと直接対話できます。Yes: We can use Azure Pipelines with Microsoft-hosted agents to interact directly with Kubernetes API endpoint.
    • いいえ:Kubernetes クラスター API エンドポイントに接続できるセルフホステッド エージェントが必要です。No: We need self-hosted Agents that can connect to the Kubernetes cluster API endpoint.

インターネット経由で Azure Stack Hub 管理エンドポイントと Kubernetes API にアクセスできるシナリオでは、デプロイに Microsoft ホステッド エージェントを使用できます。In scenarios where the Azure Stack Hub management endpoints and Kubernetes API are accessible via the internet, the deployment can use a Microsoft-hosted agent. このデプロイを実行すると、アプリケーション アーキテクチャは次のようになります。This deployment will result in an application architecture as follows:

パブリック アーキテクチャの概要Public architecture overview

Azure Resource Manager エンドポイント、Kubernetes API、またはその両方がインターネット経由で直接アクセスできない場合は、セルフホステッド ビルド エージェントを利用してパイプラインのステップを実行できます。If the Azure Resource Manager endpoints, Kubernetes API, or both aren't directly accessible via the Internet, we can leverage a self-hosted build agent to run the pipeline steps. この設計では、必要な接続が少なく、Azure Resource Manager エンドポイントと Kubernetes API へのオンプレミス ネットワーク接続のみを使用してデプロイできます。This design needs less connectivity, and can be deployed with only on-premises network connectivity to Azure Resource Manager endpoints and the Kubernetes API:

オンプレミス アーキテクチャの概要On-prem architecture overview

注意

切断されたシナリオについてWhat about disconnected scenarios? Azure Stack Hub、Kubernetes、またはその両方がインターネットに接続された管理エンドポイントを持たないシナリオでも、デプロイに Azure DevOps を使用できます。In scenarios where either Azure Stack Hub or Kubernetes or both of them do not have internet-facing management endpoints, it is still possible to use Azure DevOps for your deployments. セルフホステッド エージェント プール (オンプレミスまたは Azure Stack Hub 自体で実行されている DevOps エージェント)、またはオンプレミスの完全にセルフホステッドの Azure DevOps Server を使用できます。You can either use a self-hosted Agent Pool (which is a DevOps Agent running on-premises or on Azure Stack Hub itself) or a completly self-hosted Azure DevOps Server on-premises. セルフホステッド エージェントは、送信 HTTPS (TCP/443) インターネット接続のみを必要とします。The self-hosted agent needs only outbound HTTPS (TCP/443) Internet connectivity.

このパターンでは、各 Azure Stack Hub インスタンス上で Kubernetes クラスター (AKS エンジンを使用してデプロイおよび調整) を使用できます。The pattern can use a Kubernetes cluster (deployed and orchestrated with AKS engine) on each Azure Stack Hub instance. これには、フロントエンド、中間層、バックエンド サービス (MongoDB など)、および nginx ベースのイングレス コントローラーで構成されるアプリケーションが含まれます。It includes an application consisting of a frontend, a mid-tier, backend services (for example MongoDB), and an nginx-based Ingress Controller. K8s クラスターにホストされているデータベースを使用する代わりに、"外部データ ストア" を利用できます。Instead of using a database hosted on the K8s cluster, you can leverage "external data stores". データベース オプションには、MySQL、SQL Server、または Azure Stack Hub の外部か IaaS 内にホストされている任意の種類のデータベースが含まれます。Database options include MySQL, SQL Server, or any kind of database hosted outside of Azure Stack Hub or in IaaS. このような構成は、ここでは扱いません。Configurations like this aren't in scope here.

パートナー ソリューションPartner solutions

Azure Stack Hub の機能を拡張できる Microsoft パートナー ソリューションがあります。There are Microsoft Partner solutions that can extend the capabilities of Azure Stack Hub. これらのソリューションは、Kubernetes クラスター上で実行されているアプリケーションのデプロイに役立つことがわかっています。These solutions have been found useful in deployments of applications running on Kubernetes clusters.

ストレージとデータのソリューションStorage and data solutions

データとストレージに関する考慮事項」で説明したように、現在 Azure Stack Hub には、複数のインスタンスにストレージをレプリケートするためのネイティブ ソリューションがありません。As described in Data and storage considerations, Azure Stack Hub currently doesn't have a native solution to replicate storage across multiple instances. Azure とは異なり、複数のリージョンにわたってストレージをレプリケートする機能は存在しません。Unlike Azure, the capability of replicating storage across multiple regions does not exist. Azure Stack Hub では、各インスタンスは独自の個別クラウドです。In Azure Stack Hub, each instance is its own distinct cloud. ただし、Azure Stack Hub と Azure 間でのストレージ レプリケーションを可能にする Microsoft パートナーのソリューションを利用できます。However, solutions are available from Microsoft Partners that enable storage replication across Azure Stack Hubs and Azure.

SCALITYSCALITY

Scality では、2009 年以降、デジタル ビジネスを強化した Web スケール ストレージを提供しています。Scality delivers web-scale storage that has powered digital businesses since 2009. Microsoft のソフトウェアで定義されたストレージである Scality RING は、商用 x86 サーバーを、ペタバイト規模のあらゆる種類のデータ (ファイルとオブジェクト) 用の無制限のストレージ プールに変換します。The Scality RING, our software-defined storage, turns commodity x86 servers into an unlimited storage pool for any type of data –file and object– at petabyte scale.

CLOUDIANCLOUDIAN

Cloudian では、大規模なデータ セットを 1 つの簡単に管理できる環境に統合する無制限の拡張性を備えたストレージを使用して、エンタープライズ ストレージが簡素化されます。Cloudian simplifies enterprise storage with limitless scalable storage that consolidates massive data sets to a single, easily managed environment.

次のステップNext steps

この記事で紹介した概念の関連情報:To learn more about concepts introduced in this article:

ソリューションの例をテストする準備ができたら、高可用性 Kubernetes クラスター デプロイ ガイドに進んでください。When you're ready to test the solution example, continue with the High availability Kubernetes cluster deployment guide. デプロイ ガイドでは、コンポーネントをデプロイしてテストするための詳細な手順について説明します。The deployment guide provides step-by-step instructions for deploying and testing its components.