4. FAQ¶

よくあるお問い合わせ

4.1. サービス範囲¶

基本的な CNAP のサービス範囲に関するお問い合わせ

CNAPで障害が発生した場合、ユーザーとソフトバンクの責任分界点はどうなるのでしょうか？

コンテナプラットフォーム（AKS、GKE、EKS などのマネージドKubernetes）までがソフトバンクの責任、それより上のコンテナアプリがお客さまの責任となります。また、ソフトバンクが構築した部分（Grafanaなどのセルフモニタリングサービス）については、すべてソフトバンクの責任となります。

ユーザー側 Github のライセンス費用の扱いはどうなりますか？

お客さまの Git リポジトリ (Github等) はお客さま側での手配となります。そのためソフトバンクはライセンス費用に関与しません。

CI パイプラインの機能（Jenkinsなど）は、CNAP には含まれていないため、ユーザー側で別途用意するのでしょうか？

ビルド、テスト、コンテナイメージの作成、リポジトリへの登録についてはお客さまで用意していただく必要があります。

Kubernetesの機能は全て利用できるのでしょうか。一部制限はあるのでしょうか？

CNAP で特別に制限は設けていません。AKS、GKE、EKS などのマネージド Kubernetes の仕様に準じます。

ユーザーアプリケーションの CI パイプラインの機能は、CNAP で提供いただけますか？

お客さまのアプリケーションのビルド、テスト、コンテナイメージの作成、リポジトリへの登録についてはお客さまで用意していただく必要があります。CNAP の YAML のコードの CD 機能は提供しており、事前に登録いただいたGitリポジトリに対してコードをプッシュいただくと、お客さまの環境にリソースがデプロイされます。

4.2. サービス仕様¶

CNAP のサービス仕様に関するお問い合わせ

4.2.1. CNAP パッケージ¶

CNAP のパッケージが対応してないクラウドサービスや kubernetes リソースを作成したい場合、どうやって作成すればいいですか？

お客さまのご要望に基づき、CNAP開発メンバーがパッケージを拡充させていただきますので、まずはお問い合わせいただきますようお願いします。ご要望の中から優先順位をつけ対応させていただきますので、少々お時間いただく場合もございます。お急ぎの場合は、CNAPパッケージ以外のマニフェストを暫定的に適用することも可能です。通常のkubernetesリソースYAMLはもちろんのこと、 Google Cloud 環境では Google Cloud リソースを管理できるオープンソースの Kubernetes アドオンである Config Connector、Azure 環境リソースを管理できる azure service operator などが利用可能なため、それらのマニフェストをお客さまご自身で作成いただき、CNAP と連携する Git リポジトリに push いただければリソースが作成されます。それ以外にも、MSP のサービスとして構築することも可能ですので、その場合もお問い合わせいただきますようお願いします。

CNAP のパッケージを利用してアプリケーションを作る場合、どこまでを CNAP でカバーできるのでしょうか？

各 CNAPパッケージがサポートしている機能がカバー範囲となります。詳細は、本ドキュメント「HELM ユーザー用パッケージ」の章をご参照ください。

4.2.2. CI / CD¶

Github Actionsや、Azure DevOps など既にパイプラインを利用している場合、どのようにCNAPへ移行すればよいでしょうか？

CI は既にお客さまでご利用いただいている仕組みをそのままご利用いただけます。CD については CNAP の CD ツール (Flux) でデプロイします。

既存のCIツールからの連携（アプリケーションコードのプッシュ → ビルド → デプロイの流れ）は何か具体例として良い方法があれば教えて頂けないでしょうか？

CI でコンテナイメージを作った後にCNAPにデプロイするようなシナリオであれば、CI のワークフローに続けてCNAP Gitリポジトリ（ユーザーリポジトリ）のマニフェストのイメージバージョンを書き換える処理を追加いただく必要があります。なお、事前にCNAP上で本番環境と検証環境を分けて用意いただき、検証環境にデプロイ後、E2E テストといったアプリケーションの動作確認を行い、成功した場合に本番環境にデプロイするというワークフローを組んでいただくとよいかと思われます。また、本番環境に対してであれば、Git リポジトリに PullRequest を作るところまで自動化することも可能です。

ユーザーが用意する git リポジトリとの連携はどのように行なって、どの範囲のマニフェストが適用されますか？

お客さまの kubernetes クラスタ内にある CDツール (Flux) が定期的に Git リポジトリに対しポーリングしています。 CNAP と連携する Git リポジトリでは、指定された path の直下にある全てのマニフェストをクラスタに適用します。この際サブフォルダ以下に配置されたマニフェストは適用されません。サブフォルダ以下に配置されたマニフェストを適用したい場合 path に指定されたフォルダに kustomization.yaml を置く必要があります。 kustomization.yaml は kustomize の設定ファイルであり、これを活用することで、サブフォルダに配置されたマニフェストを適用できます。

ユーザーが用意する git リポジトリに制約はありますか？

CNAP クラスタから接続できること、SSH が使える必要がございます。それ以外は特に制約はなく、GitHub、GitLab、パブリッククラウド上のマネージドGitなど自由にご利用いただけます。なお、CNAP で動作確認済の Git リポジトリについては本ドキュメントの「検証済項目一覧」をご参照ください。

1 クラスターで複数の git リポジトリとの連携は可能でしょうか？また、複数の branch との連携は可能でしょうか？

どちらも可能です。追加方法の詳細手順は本ドキュメントの「チュートリアル」の章をご参照ください。

Private な Docker Hubからイメージを取得したい場合、どのように指定するのが適切でしょうか?

Docker レジストリの認証情報を事前に KMS に登録しておき、basic-deploymentパッケージで imagePullSecrets.[] に利用する imagePullSecret の設定を列挙します。これにより、自動的にクラスタ上に secret が作成され、Pod が参照するように設定されます。なお、Google Cloud の場合、同一プロジェクトに存在する ArtifactRegistry からのイメージ取得には imagePullSecrets の設定は必要ありません。

CNAP と連携している Github リポジトリ内のマニフェストはどのタイミングでトリガーされますでしょうか。

Flux により、Git リポジトリを 1 分間隔で監視しています。リポジトリの監視対象のブランチに変更が入るとトリガーされます。

latest タグが付いた Docker イメージが更新された場合、CNAP 側での検知方法はありますでしょうか？

Deployment リソースの pullPolicy によって、Kubernetes がコンテナイメージをどのようにプルするかを制御できます。デフォルトは、IfNotPresent ですので、latest タグを使用する場合は、 Always に変更する必要があります。 Always ポリシーでは、コンテナの起動または再起動のたびに、Kubernetesは常にリモートのレジストリから最新のイメージをプルしようとします。イメージの変更をポーリングしたり、イメージが更新されたかどうかを自動的に検出したりしないため、CI / CDパイプラインのスクリプト内で Pod を強制的に再起動するよう設定する必要があります。

4.2.3. オートスケール・冗長化¶

クラスタ全体の負荷が想定より大幅にかかり、ノードの max 台数追加が必要となった場合はどのようなフローで追加されますか？

ノード数がオートスケールの max 台数に到達した際に、CNAP の監視でアラートが通知されます。そして、増設が必要とお客さまが判断された場合には、サービスカタログ（ノードプール設定変更）から増設（node pool の max 台数の変更）の依頼をしていただきます。想定外のコストがかかってしまうことを避けるため、自動で max 台数の変更は行いません。max 台数に達していない場合は、max台数に達するまで自動でオートスケールいたします。

ノードのスケールアウトの契機、条件は何ですか？

クラウドベンダーの仕様 (AKS/GKE/EKS) に依存します。主にノードのリソース不足の影響を受けた Pod が Pending (スケジュール不可) 状態となることがスケールアウトの契機となります。 CNAP側では特に制限は行っておりません。

ノードプール内のノードが分散配置されているか確認したいです。どうやって確認すればいいですか？

> kubernetes describe nodes | grep "topology.kubernetes.io" コマンドにより確認可能です。

4.2.4. DNS 設定¶

ヒアリングシートで zone_name の設定値はどのように記載すればいいですか？

DNSゾーンを記載ください。DNSゾーンとは、インターネットのドメイン名の管理において、あるDNSサーバ（ネームサーバ）が自ら管理するドメインの範囲のことです。例えば、アプリのURLが

"www.example.com" の場合、"example.com"の部分をご記載ください。

"hostname.subsidiary.example.com" の場合、"subsidiary.example.com"の部分をご記載ください。

登録するドメインに制約はありますでしょうか？

特にございません。ドメイン名を新規に購入する、もしくはお客さまが既に所有しているドメインのサブドメインどちらも登録可能です。（例えば example.com、sub.example.com のどちらも登録可能です）

クラウドベンダーのマネージドDNSサービスへのDNSの委任はどうして必要なのでしょうか？

TLS証明書の自動発行や、DNSレコードの自動更新機能を利用するためには、マネージドDNSサービスでDNSレコードを管理する必要があります。そのために、親ゾーンからクラウドベンダーのマネージドDNSサービスに委任（子ゾーンのネームサーバーを指定するためのNSレコードを親ゾーン側で設定すること）していただく必要があります。

CNAPでは、DNSサーバーにAレコードが自動登録されると思いますが、どういったIPv4アドレスが登録されますか？また、複数のホスト名が全て同一IPアドレスでアクセス出来ますが、どのような仕組みでアクセスできるのでしょうか？

クラウドサービスの LoadBalancer に紐づく IP アドレスが A レコードとして登録されます。クラウドサービスの LoadBalancer に到達後、そのネクストホップにある Istio Ingress Gateway（Kubernetes L7 LoadBalancer）がホスト名に基づいて Kubernetes service にリクエストを振り分けます。クラウドサービスの LoadBalancer から先はホスト名によりルーティングされるため同一 IP でアクセスできます。なお、このホスト名は basic-deployment パッケージにより Kubernetes VirtualService にて設定されます。

4.2.5. 証明書管理¶

CNAP環境で使用される証明書の種別・選択肢をご教示いただけないでしょうか？

使用可能なのは、Let's Encrypt の証明書、お客さまでお持ちの証明書となります。AWS の L7構成におきましては、クラウドのマネージド証明書(ACM)をご利用いただけます。

証明書は Let's Encrypt しか使えないでしょうか。証明書は別途指定できますか？

AWS の L7構成におきましては、クラウドのマネージド証明書(ACM)をご利用いただけます。また、有償のOV、EV証明書といったお客さまの持ち込み証明書もご利用いただけます。具体的な利用方法はチュートリアルをご参照ください。

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

現行の L4 ロードバランサを L7 ロードバランサに変更し、かつWAFを有効にするといったネットワーク構成の変更をしたいのですが可能でしょうか？

可能です。サービスカタログからご依頼ください。

4.2.7. サービスメッシュ¶

複数のPodを利用するアプリケーションをデプロイしたい場合、Pod ⇄ Pod 間の通信方法は互いの URLを指定する事が望ましいでしょうか。もしくは何か別に推奨するコンテナ間の通信方法がありますか？

同一クラスタ内であれば、Kubernetes service にアクセスすることでpodと通信することができます。Podに直接アクセスするのは推奨されません。

4.2.8. セキュリティ¶

コントロールプレーン(Master API)のプライベート化は可能でしょうか？

コントロールプレーンのプライベート化は基本機能として提供しておりません。個別サービスによりご要望に応じて提供できる場合がございますので、まずはお問い合わせいただきますようお願いします。

4.2.9. ログ設定¶

アプリケーションログ例えば、PHP の laravel の場合、/var/www/html/example-app/storage/logs/laravel.log というパスにデフォルトで出力しています。アプリケーションログ以外に収集したいログがある場合どのように設定しますか？

標準・エラー出力に出力されたログは自動的に収集されますが、特定のファイルに出力されたログを収集する機能はありません。標準・エラー出力に出力するようご検討をお願いします。

4.2.10. メトリクス監視¶

コンテナがスケールした場合、周辺環境（監視やダッシュボード）もスケールに合わせて設定が動的に変わりますか？

スケールアウトした場合、自動的にダッシュボードに追加されます。

メトリクス監視について、どこまで監視していますか？

CNAP の基盤の部分のみ監視しています。お客さまのアプリケーションの監視は、お客さまご自身、もしくは MSP サービスの個別対応とさせていただいております。

4.2.11. バージョン管理¶

Kubernetes バージョンはユーザー管理でしょうか？

クラスタは、ソフトバンク管理のため、クラスタバージョンの管理もソフトバンク管理となります。標準では Kubernetes 自動アップグレードをONとなっています。AKS,GKEに upgrade channel を設定し自動アップグレードを行います。（ Channelは、regular/GKE、stable/AKS となっています）自動アップグレードをOFFにしたい場合には、導入支援サービスを使用していただいて、メンテナンス計画などを立てる必要があります。

Kubernetesのバージョンやスケーリングポリシーなどは、ユーザーがコントロール可能でしょうか？

バージョンについて、現時点では「自動アップグレード」となり、お客さまによるコントロールは不可としております。

4.2.12. ユーザー設定¶

YAML内のパラメーター等を定義する箇所について、使えない文字列はありますか？Pod名やラベルを設定しようとしています。

使用できる文字は Kubernetes の仕様に従うので、公式ページで確認していただきますようお願いします。 Pod名: 253文字以内。英小文字、数字、「-」または「.」のみを含む。英数字で始まる。英数字で終わる。ラベル: 63文字以下である必要があり、文字列の最初と最後は英数字([a-z0-9A-Z])で、文字列の間ではこれに加えてダッシュ(-)、アンダースコア(_)、ドット(.)を使うことができます。

4.3. トラブルシュート¶

Kubernetes のワークロードのステータスがOKになったのを確認してからアクセスすると "upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: delayed connect error: 111" という表示がされる事がありますが何が原因ですか？

deployment リソースがデプロイされてから、クラウドのリソースに反映されるまでにタイムラグがあることが原因だと思われます。しばらく待ってからアクセスするようお願いします。

fluxのエラーログをkubectlのコマンドで得る事は出来ますか？

fluxのエラーログについては以下の 3 つのコマンドで確認が可能です

$ kubectl logs -n flux-system deployment/source-controller

$ kubectl logs -n flux-system deployment/kustomize-controller

$ kubectl logs -n flux-system deployment/helm-controller

一部podの削除や停止、一部ノードの削除や停止をすることは出来ますか？

CNAPの標準の構成ではクラスタやノードの停止、再起動を行う権限をお客さまには付与しておりません。もし該当の操作が必要な場合には個別調整させていただきますので、お手数ですがご連絡いただきますようお願いします。なお、お客さまご自身でCNAPのマニフェストをpushしてデプロイされた pod については、マニフェストを削除することで pod も削除されます。