サービス作成
同じサービス名を使用できないのはなぜですか。
サービス名はクラスター内でサービスを識別するための唯一のものです。サービス名+アクセスポートによって、サービス同士が互いアクセスすることができます。
サービスの作成はTencent Cloud以外の、dockerhubイメージのようなサードパーティイメージを使用可能ですか。
ホストでdocker loginコマンドを実行し、サードパーティのイメージリポジトリにログインして、イメージを取得できます。
パブリックネットワークの使用のための前提条件はなんですか。
クラスタ内のCloud Virtual Machine (CVM) がパブリックネットワーク帯域幅をもつことを確認してください。パブリックネットワーク帯域幅が無ければ、パブリックネットワークサービスの作成に失敗します。
メモリ制限、CPU制限をどのように記入しますか。
サービス作成時の特権とはなんですか。
特権を有効化すると、コンテナ内のアプリケーションが本当のroot権限を持つようになります。nfsサーバーの構築など、コンテナ内のアプリケーションでより高度なシステムオペレーションを行う際に有効化を推奨します。
Cloud Load Balancer (CLB) 作成時にセキュリティグループを指定できますか。
現在、以下の２つの方法によって指定できます：
既存CLBを使用する。CLBを作成してセキュリティグループを設定した後に、サービスにマウントします。詳細は、サービスが既存CLBを使用する方法をご参照ください。
サービスの中で TkeServiceConfig によってセキュリティグループを設定します。CLB作成時に設定に従って対応するセキュリティグループを使用します。この機能を使用するには、 チケット申請 に従って申請してください。 CLBのIPを通して、クラスター内でサービスにアクセスすると、アクセスできない恐れがあります。
一般的に、4層CLBは複数のノードをバインディングして、real server (rs) として使用します。一定の確率でメッセージループバックが失敗する恐れがあるため、使用時に client と rs は同一のCVM上に置いてはいけません。
PodがCLBにアクセスする際に、PodをソースIPとします。ソースIPがプライベートネットワークに転送された場合も、CLBはsnat処理によってソースIPをノードIPに変換しません。そうしないと、CLBがメッセージを受信する際、どのノードが転送したものか判断することが出来ないため、ループバック回避ポリシーが機能せず、すべてのrsが転送される可能性があります。Client が所在するノードに転送されると、CLBはリターンパケットを受信出来ないため、アクセスに失敗します。
コンテナ数の更新
コンテナ数を更新する際にどのような点に注意すべきですか。
コンテナ作成失敗を防ぐため、CPUとメモリリソースが十分確保されていることをご確認ください。
コンテナ数に0を指定できますか。
できます。コンテナ数に０に指定することで、サービス設定をセーブし、占用したリソースを解放できます。
サービス設定の更新
ローリングアップデートはサポートされていますか。
ローリングアップデート及びクイックアップデートの２つがサポートされています。
パブリックネットワークCLBはプライベートネットワークCLBに切り替え可能ですか。
可能です。現在、パブリックネットワークからVPCプライベートネットワークへの切り替え、VPCプライベートネットワークからパブリックネットワークへの切り替え、及びVPCの異なるサブネット間の切り替えが可能です。詳細はサービスライフサイクル管理をご参照ください。
サービスに対してCLBリソースのライフサイクルを管理する場合、CLB及びそのパブリックネットワークIPは解放されます。
パブリックネットワークからプライベートネットワークへの切り替えは即時に実行されるのではなく、パブリックネットワークCLBサービスがオフラインになってから、プライベートネットワークCLBがサービス提供を開始するまで、一定時間を要します。クラスター内でプライベートネットワークサービスリソースを予め設定し、テストを実施することを推奨します。トラフィックの切り替え完了後、パブリックネットワークのサービスリソースを削除してください。
サービス削除
作成されたCLBは、サービス削除後に自動的に廃棄されますか。
サービスが削除されると、サービス作成時に作られたCLBは削除されます。サービス作成時に選択した既存のCLBは影響を受けません。
サービス削除によってデータは影響を受けますか。
サービスを削除してもコンテナは削除されません。データは影響を受けないため、バックアップする必要はございません。
サービス運用
コンテナシステム時間の北京時間への設定方法は？
コンテナはデフォルトでUTC時間を採用しており、コンテナ使用時にコンテナシステム時間と北京時間に８時間の差が生じることがあります。dockerfile にタイムゾーンファイルを作成することで解決できます。詳細は コンテナ内タイムゾーンの不一致について をご参照ください。 ubuntu や php 、busybox といったDockerhubの一部のイメージがコンテナサービス内で異常が発生したときの対処方法は？
起動コマンドを設定していない、またはデフォルトの起動コマンドが bashである場合に、コンテナがランチャープログラムを実行してから終了するシステム異常が発生します。コンテナが継続して動作するよう、コンテナ内のPIDが１であるプログラムは必ず常駐プロセスでなければいけません。これは、PIDが１であるプロセスが終了すると、コンテナも終了するためです。centos といった一部のイメージについては、 /bin/bash を実行コマンドとして使用し、-c sleep 800000 を実行引数としてサービスを作成できます。コンソール上で実行引数を入力する際は、-c と sleep 800000 を２行にわけて入力する必要があります。
現在確認されているデフォルトパラメータでサービスを起動できないイメージには以下のものがあります：clearlinux、ros、mageia、amazonlinux、ubuntu、clojure、crux、gcc、photon、java、debian、oraclelinux、mono、bash、buildpack-deps、golang、sourcemage、swift、openjdk、centos、busybox、docker、alpine、ibmjava、php、python。