1. 概要¶

Cloud Native Application Platform (CNAP) はクラウドのマネージド Kubernetes に対して必要な設定を全て済ませたクラスタを提供し、さらにアプリケーションの運用や GitOps を行ううえで便利な追加機能を提供します。

CNAP 独自の機能は Kubernetes クラスタのアドオンとして提供されるため Kubernetes とそのマネージド版である、 Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) の機能は基本的にそのまま利用することができます。

初期導入は CNAP の提供する機能をそのまま利用することによって開発コストを下げ、高度な設定が必要になってきた際には、CNAP をべースにカスタマイズをしていくことが可能です。

1.1. クラウドサービスの統合¶

各クラウドはマネージド Kubernetes クラスタとその他のクラウドサービスとの連携機能を提供しています。これらを利用するには、Kubernetes クラスタに固有の設定が必要になります。また、クラスタ内のリソースを作成する都度に追加の設定が必要になる場合があります。

CNAP ではこれらの連携設定が済んだ Kubernetes クラスタ環境を提供します。 CNAP のパッケージを利用して適用したワークロードに対しては、特に設定の変更を行なわなくてもこれらの連携設定が自動的に適用されます。

1.1.1. 認証の統合¶

クラスタ内のワークロード（コンテナなど）がクラウドサービスにアクセスできるように、 Kubernetes 内の認証と IAM 認証の連携設定と必要な権限の付与を CNAP が行います。

Kubernetes クラスタ内のワークロードから RDB などのクラウドのマネージドサービスにアクセスするためには、クラウドの IAM による認証を行う必要があります。この方法には大きく分けて以下の2つの方法があります。

認証用の鍵ファイルを利用する
OIDC(OpenID Connect) 認証を利用する

鍵ファイルによる認証は鍵自体のメンテナンスが必要になったりクラスタ内に機密情報が残るなど、あまり好ましくありません。CNAP では OIDC 認証を利用したクラウドサービスとの連携機能を提供します。

Kubernetes クラスタ内のワークロードの認証は ksa(Kubernetes ServiceAccount) に対して行われます。これに対して、クラウドの IAM 認証は独自のアカウントによって行われます。このためワークロードからクラウドサービスにアクセスするめには、ksa を利用して IAM 認証を行う WorkloadIdentity という仕組みを利用する必要があります。この ksa と IAM の連携を OIDC を利用して行うための設定を CNAP が行います。

これによりクラスタ内に、クラウドにアクセスするためのクレデンシャル情報を残すことなくクラスタ内のワークロードからクラウドサービスを利用することができるようになります。

1.1.2. クラウドサービス設定¶

Kubernetes 上のコンテナワークロードはステートレスな設計でより効果を発揮します。このため、ステートフルな RDB やストレージといった機能はクラウドのマネージドサービスを利用することが推奨されます。

通常クラウドサービスと Kubernetes の設定は異なる設定インターフェイスを用いて管理する必要がありますが、 CNAP ではこれらの設定管理に一貫性を持たせるため Kubernetes マニフェストによってクラウドサービスの設定を行う機能を提供します。これによって、アプリケーションの実行に必要な設定を全て Kubernetes マニフェストの yaml ファイルによって管理することができるようになります。これらの yaml ファイルを Git で管理することによって、インフラ構成のバージョン管理ができるようになり、後述する GitOps 機能を利用することで構成の定義と実際の設定が完全に一致するデプロイ運用が可能になります。

注釈

Kubernetes クラスタやノードグループ、NAT、デフォルトのロードバランサー、証明書、DNS、パブリックIPなどの設定変更は、サービスカタログからご依頼ください。

1.1.3. シークレット管理¶

前述の OIDC 連携によってクラウドサービス連携のための鍵ファイルは基本的に不要になりますが、それ以外の機密情報をクラスタ上で利用しなければならないケースに対応するための、より安全な方法を提供します。

Kubernetes には Secret というリソースがありこれに機密情報を格納することができます。しかし、これ自体が yaml のマニフェストであるため、Git にそのまま入れてしまうと、 Git リポジトリ内に機密情報が残ることになります。 Secret を定義した yaml ファイルを暗号化して Git リポジトリで管理する方法もありますが、リソースを複数の環境にデプロイするとを考慮すると効率的ではなくなるため、機密情報はマニフェストから分離して管理する必要があります。

CNAP ではこれを実現するためクラウドのキーマネージメントサービスと連携して Kubernetes の Secret リソースを作成する機能を提供します。これによって、Secret の作成はキーマネージメントサービスに登録されたリソースを指定するだけでよくなり、機密情報の実体をマニフェストに組み込む必要がなくなります。さらに、キーマネージメントサービス側のデータ更新と Secret が同期するため、メンテナンスも容易になります。

1.2. CNAP パッケージ¶

CNAP では一般的なアプリケーション構成を簡単に構築できるパッケージを提供しています。これらのパッケージは Pod などの Kubernetes リソースだけでなく、クラウドデータベースやオブジェクトストレージなどのマネージドクラウドサービスの設定を行う機能も持ち、パッケージに簡単な設定を行うだけで基本的な構成を実現できるように考慮されています。

1.2.1. アプリケーションインフラ構成¶

CNAP パッケージを利用すると、コンテナの実行に必要な環境や、マネージドサービスに必要な追加設定を自動的に設定することができます。

例えば、Kubernetes の Deployment マニフェストを利用した場合、コンテナのライフサイクルと外部リソースのマウント設定などはできますが、ネットワーク設定等は別途行う必要がありますが、 CNAP の basic-deployment パッケージを利用した場合は、Deployment の設定に加えて、クラスタ内ネットワーク、クラスタ外ネットワークからのアクセス、 DNS の登録、マネージドサービスへのアクセス権の設定といったアプリケーションに必要なインフラの構成をまとめて行うことができます。また、これらの設定は必要最小限の項目で設定できるように工夫されています。

CNAP パッケージは Kubernetes マニフェストを利用して、Kubernetes リソースやカスタムリソースを展開します。 CNAP パッケージでサポートされていない機能は、CNAP パッケージで作成したリソースを中心に、独自のマニフェストを組み合わせることで実現することができます。

詳細についてはこちらのアプリケーションの構築のチュートリアルを参照してください。

1.2.2. バージョン管理¶

CNAP パッケージ及び、パッケージを構成するために必要なカスタムリソースは OSS とクラウドサービスを組み合わせて構成されています。 OSS のバージョンアップ及びバージョンアップにともなうリソースの互換性の維持は CNAP が自動的に行います。

重要

OSS やクラウドサービスのバージョンアップによって発生した設定項目の変更は基本的には CNAP パッケージによって吸収されます。

ただし、OSS やクラウドサービスの仕様が大幅に変更された場合、CNAP パッケージでの変更差分の差分の吸収が困難となり、 CNAP パッケージの仕様も変更される可能性があります。

このような変更が発生した場合、構成を破壊する危険があるため、お客さまが利用する CNAP パッケージのバージョンの自動更新は行なわれません。

変更への対応は、お客さま自身で利用する CNAP パッケージのバージョンアップおよび、手動での設定ファイルの書き換えを行う必要がありますが、これらの手順については情報提供していきます。

1.2.3. 複数環境へのデプロイ¶

CNAP パッケージの実体は helm チャートです。これを CNAP の提供する Application マニフェストを利用してデプロイします。 Application マニフェストでは、 CNAP パッケージ名（helmチャート名）、パッケージバージョン、パッケージのオプション設定値を定義でき、その定義に基づいて CNAP がパッケージをインストールします。この際必要となる Kubernetes クラスタの設定情報や、クラウド環境の基本設定情報は指定する必要がなく自動的に反映されます。これによって Application の設定にクラスタに依存する設定を含める必要がなくなり、開発、ステージング、本番など複数のクラスタを運用している場合でも、クラスタ環境設定を書き変えることなくアプリケーション固有の設定のみの変更で適用することができるようになります。

1.2.4. 外部パッケージの利用¶

Application マニフェストは CNAP の提供する helm チャート以外も扱うことができますが、この場合はクラスタ環境設定の自動適用は行われません。

1.3. GitOps 環境¶

CNAP では GitOps を利用した CD(Continuous Delivery) 機能を提供します。 CNAP の CD は flux を利用し Git のリモートリポジトリに配置された Kubernetes マニフェストを Git のオペレーションに従ってクラスタに適用します。

これによって GitHub などの GitWeb サービスのワークフローを利用したインフラ管理が可能になります。

1.3.1. GitOps の仕様¶

CNAP と連携する Git リポジトリでは、指定された path の配下にある全てのマニフェストをクラスタに適用します。この際サブフォルダ以下に配置されたマニフェストは適用されません。 path に指定されたフォルダに kustomization.yaml が存在する場合は、その設定に従って適用されます。 kustomization.yaml は kustomize の設定ファイルであり、これを活用することで、複数のクラスタや Namespace に対して効率的にマニフェストを適用することができます。

1.3.2. ユーザー設定¶

CNAP で GitOps による運用を適切に行なうためには CNAP 用の設定が行なわれた、 Git リポジトリや Namespace を使用する必要があります。この設定をお客さま自身でも行えるようにするために、ユーザー設定機能を提供しています。

CNAP では申込時に指定したリポジトリに GitOps に必要なクラスタとの連携設定を行います。この Git リポジトリを1つ目の Git リポジトリとし、 2 つ目以降のリポジトリが必要になった場合はこの1つ目のリポジトリを用いて GitOps による設定を行います。

CNAP クラスタにはデフォルトで設定済みの Namespace が提供されますが、 Namespace を追加する場合にも1つ目のリポジトリを用いて GitOps によって設定を行います。

ユーザー設定の詳細についてはこちらを参照してください。

1.4. Network 環境¶

CNAP では、クラスタ内ネットワーク、外部ネットワークの双方を適切に設定するための様々な機能を備えています。

1.4.1. ロードバランサー設定¶

Kubernetes クラスタ内のサービスに外部からアクセスする場合はロードバランサーを経由します。 CNAP ではあらかじめデフォルトのロードバランサー設定がされたクラスタが提供されるため、 basic-deployment パッケージをデプロイするだけでロードバランサーを利用することができます。

ロードバランサーのタイプ¶

CNAP では外部から Kubernetes 上のサービスにアクセスするために以下のいずれかのロードバランサー(ingress)の設定がされています。

L4 ロードバランサー（ネットワークロードバランサー）

クラスタネットワーク内の istio で TLS の終端が行われます。 L4 ロードバランサーには単一のクラスタへのルーティング機能を提供します。
L7 ロードバランサー（アプリケーションロードバランサー）

ロードバランサーで TLS の終端が行われます。クラウドサービスの提供する WAF 機能等を利用することができます。

クラウドサービスの提供する WAF や CDN の機能を利用する計画がある場合は L7 ロードバランサーを選択します。

注釈

デフォルトのロードバランサーの設定変更は、サービスカタログからご依頼ください。 INGRESS パッケージを利用することで、ロードバランサーを新規追加し、WAFの有効化などの設定変更・削除をユーザーセルフで行うこともできます。

1.4.2. サービスメッシュ設定¶

CNAP ではクラスタ内ネットワークを管理するサービスメッシュに istio を採用しています。クラスタ内部及びクラスタ外からのネットワークルーティングは istio によって行われます。これらの設定は CNAP の提供するパッケージ内で自動的に設定されるようになっているため、特に追加の設定を行わなくても利用することができます。

1.4.3. DNS 設定¶

CNAP でインストールしたパッケージにドメインを割り当てた場合、DNS への登録は自動的に行われます。この機能を利用するためには、クラウドの DNS サービスにゾーンを委任しておく必要があります。

注釈

DNS パッケージを利用することで、DNSレコードをユーザーセルフで追加することもできます。

1.4.4. 証明書管理¶

CNAP のパッケージを利用すると Web アプリケーションを公開する際に必要となる TLS 証明書の発行と更新の管理を自動で行うことができます。 L4 ロードバランサーを利用している場合は Let's Encrypt の DV 証明書。 L7 の場合は Let's Encrypt もしくはクラウドのマネージド証明書が発行されます。

また、証明書の自動発行を利用せず、外部で発行した証明書を登録することも可能です。

詳細はこちらのセルフマネージドTLS証明書の設定方法を参照してください。

1.5. 管理¶

CNAP は GitOps によるオペレーションでインフラ設定コードの一貫性を維持するため、リソースを操作するための専用の管理インターフェイスは提供していません。

リソースの状況を確認するためには、各クラウドの提供するマネージド Kubernetes 用の管理インターフェイスもしくは、 kubectl などのクライアントアプリケーションを利用します。

警告

前述の通り CNAP の提供する GitOps 機能では、設定とリソースの状態を常に同期します。 Git 以外のインターフェイスから行った変更は Git リポジトリで定義された設定に書き戻されます。恒久的な変更の適用は常に GitOps で行い、管理インターフェイスでは状況の確認のみを行う運用を推奨します。

1.5.1. デプロイ状況の確認¶

デプロイしたワークロードが正常に稼動しているかどうか確認するためには、適用したマニフェストのステータスを確認します。

CNAP の Application を利用すると、 application.managed.msp.sbopsv カスタムリソースが作成されるため、このカスタムリソースのステータスを確認します。このリソースに問題が発生している場合は Application のインストールしようとしている helm チャートのステータスを確認します。 helm チャートのインストールを行うカスタムリソースは helmreleases.helm.toolkit.fluxcd.io で Application に指定した name を含む名前で作成されているため、このリソースのステータスを確認することで失敗の原因を特定することができます。

1.5.2. モニタリング¶

Application を利用して作成したワークロードはモニタリングの対象になります。ワークロードの動作ログ、アクセスログ、メトリクスはクラウドのマネージド Prometheus に集約され、集約された情報は Grafana を介して参照することができます。 Prometheus、Grafana は、Kubernetes クラスタと連携設定が済んだ状態で提供されます。

1.5.3. アラート設定¶

収集したメトリックス情報を元に Grafana に対するアラートを設定することができます。

詳細についてはこちらの Grafanaの利用方法を参照してください。

1.6. CNAP の範囲外のサービス¶

CNAP はクラウドネイティブなアプリケーションの管理において、以下の機能を提供していません。必要に応じてお客さまでご用意いただくか、ソフトバンクの推奨する代替サービスのご利用をご検討いただきますようお願いします。

1.6.1. コンテナ化 (代替サービス推奨)¶

コンテナ化は、アプリケーションとその依存関係を一つのパッケージ（コンテナ）にまとめるプロセスです。これにより、アプリケーションが異なる環境間で一貫して動作することが保証されます。

コンテナ化には主に以下のプロセスが含まれますが、ソフトバンクでは MSP DevOpsソリューションにて提供しており、こちらを推奨しています。

マイクロサービスの分割 * アプリケーションを複数の独立したマイクロサービスに分割します
コンテナの作成 * 任意のサイズのアプリケーションと依存関係をコンテナ化します

1.6.2. ソースコード管理 (代替サービス推奨)¶

ソースコード管理サービス (Github, Gitlab など) 自体は、お客さまが既にアプリケーション開発においてご利用中であることを想定し、CNAP では提供しておりません。もしご利用でない場合において、ソフトバンクによる導入を希望される場合は MSP 導入支援サービスにてお客さま個別に対応します。既にご利用中のソースコード管理サービスで CNAP のマニフェストを管理することにより、アプリケーションエンジニアがアプリとインフラ両方を効率的に管理することができます。

お客さまの kubernetes クラスタ内にある CDツール (Flux) が定期的にお客さまの Git リポジトリにポーリングすることで GitOpsを実現します。

Git リポジトリは、CNAP クラスタから接続でき、SSH が使えればCNAPに対応可能であり、特に制約はございません。なお、CNAP で動作確認済の Git リポジトリについては検証済ソース管理サービス一覧をご参照ください。

1.6.3. CI パイプライン (代替サービス推奨)¶

CI パイプラインには主に以下のプロセスが含まれますが、ソフトバンクでは MSP DevOpsソリューションにて提供しており、こちらを推奨しています。

自動ビルド * コードがリポジトリにコミットされるたびに、自動的にビルドプロセスがトリガーされます。これには、コンパイル、依存関係の解決、パッケージングが含まれます。
自動テスト * ユニットテスト、統合テスト、UIテストなどの自動テストを組み込むことでビルドプロセスを効率化できます。テストの成功は、コードがリリースのための品質基準を満たしていることを示します。

1.6.4. トレーシング (将来的に対応予定)¶

トレーシングはアプリケーションのリクエストフローやパフォーマンスメトリクスを追跡し、システムの動作を理解するためのツールですが、 CNAP では現在提供しておりません。今後、サービスメッシュ内のサービス間のトラフィックフローを可視化し、構成の問題やパフォーマンスのボトルネックを特定するツールとして Kiali の提供を予定しています。将来的に対応予定ですが、導入時期は未定です。

1.6.5. ユーザーアカウント管理 (代替サービス推奨)¶

ユーザーがクラウドコンソール等の管理画面を通じてリソースへアクセスするための適切な権限管理や、アカウントの管理を行います。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。

1.6.6. APIマネージメント (代替サービス推奨)¶

レートリミットとクォータ管理: APIの利用制限を設け、過剰なトラフィックによるサービスの障害を防ぐ機能。

API分析とモニタリング: APIの使用状況やパフォーマンスを監視し、問題を特定して対処する機能。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。（導入時期は未定ですが、レートリミットはサービスメッシュでの提供を予定しています）

1.6.7. コンプライアンスと脆弱性スキャン (代替サービス推奨)¶

コンプライアンスと脆弱性スキャンは、セキュリティポリシーの遵守とシステムの脆弱性を検出するためのプロセスです。ツールやサービスを使用して、定期的にスキャンを行い、セキュリティのリスクを評価します。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。

1.6.8. ストリーミングプラットフォームの設定 (代替サービス推奨)¶

ストリーミングプラットフォームは、リアルタイムのデータストリーム処理を行うためのシステムです。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。

1.6.9. イメージのセキュリティスキャン (代替サービス推奨)¶

コンテナイメージのセキュリティスキャンは、脆弱性やセキュリティリスクを検出するためのプロセスです。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。

1.6.10. ソフトウェア配布 (代替サービス推奨)¶

コンテナイメージそのもの、もしくはイメージに関連するメタデータ（例：バージョン情報、ハッシュ値、ファイルサイズなど）を署名し、検証する仕組みを提供します。これにより、Kubernetesが署名されたイメージのみを受け入れるようなることで、正当なソースから提供され、改ざんされていないことを保証します。

ソフトバンクでは、 MSP 導入支援サービスにてお客さま個別に対応します。