カテゴリー | 評価項目 | タイプ | 影響の説明 | 評価の参照 |
クラスター | クラスター作成前に、業務シナリオを踏まえて事前にノードネットワークとコンテナネットワークを計画することで、その後の業務拡張が制限されないようにします。 | ネットワーク計画 | クラスターの存在するサブネットまたはコンテナネットワークセグメントが小さいと、クラスターが実際にサポートする有効ノード数が業務に必要な容量より少なくなる可能性があります。 | |
| クラスター作成前に、Direct Connect、Peering Connection、コンテナネットワークセグメントとサブネットネットワークセグメントなどの関連ネットワークセグメントの計画を事前に整理することで、ネットワークセグメントの競合が発生して業務に影響することがないようにします。 | ネットワーク計画 | 単純なネットワーキングシナリオの場合はページの表示に従ってクラスターの関連ネットワークセグメントを設定し、競合を避けます。Peering Connection、Direct Connect、VPNなどの、業務上の複雑なネットワーキングシナリオの場合は、不適切なネットワーク計画によって業務全体の正常な相互アクセスに影響が出ます。 | - |
| クラスター作成の際、自動的にデフォルトのセキュリティグループを新規作成してバインドし、業務ニーズに応じてカスタムセキュリティグループルールを設定することもできます。 | デプロイ | セキュリティグループは重要なセキュリティ隔離手段であり、セキュリティポリシーの設定が不適切な場合はセキュリティ関連リスクおよびサービスの接続性などの問題が生じる可能性があります。 | |
| ContainerdとDockerはTKEが現在サポートしているランタイムコンポーネントであり、適用ケースがそれぞれ異なります。クラスター作成の際は、業務シナリオに応じて適切なコンテナランタイム（Container Runtime）コンポーネントを選択してください。 | デプロイ | クラスターの作成後にランタイムコンポーネントおよびバージョンを変更する場合は、クラスター内のノードプールに所属していない増分ノードにのみ有効であり、既存ノードには影響しません。 | |
| デフォルトでは、Kube-proxyはiptablesを使用してServiceとPod間のロードバランシングを実現します。クラスター作成の際は、IPVSを迅速に有効化してトラフィックを受け入れ、ロードバランシングを実現することができます。 | デプロイ | 現在はクラスター作成時のIPVS有効化をサポートしており、それ以降は全クラスターに対して有効になり、無効化することはできません。 | |
| クラスター作成の際は、業務シナリオに応じて、独立クラスターとホスティングクラスターのうちどちらか適切なクラスターモードを選択します。 | デプロイ | ホスティングクラスターのMasterとEtcdはユーザーリソースではなく、Tencent Cloudのテクニカルチームが一元的に管理および保守を行っているため、ユーザーはMasterとEtcdのデプロイ規模およびサービスパラメータを変更することはできません。変更したい場合は独立デプロイモードのクラスターを選択してください。 | |
ワークロード情報 | ワークロードの作成時にCPUとメモリの制限範囲を設定することで、業務の堅牢性を向上させる必要があります。 | デプロイ | 同一のノード上に複数のアプリケーションをデプロイする場合、リソースの上限と下限を設定していないアプリケーションに、アプリケーションの異常によるリソース漏洩の問題が発生した場合、その他のアプリケーションにリソースが割り当てられずにエラーが起き、かつその監視情報にも誤差が生じる可能性があります。 | |
| ワークロードの作成時にコンテナヘルスチェック（「コンテナLivenessチェック」および「コンテナReadinessチェック」）を設定できます。 | 信頼性 | コンテナヘルスチェックが設定されていないと、ユーザーの業務に異常が発生した場合にPodが認識できず、自動的に再起動してサービスを再開することができなくなり、最終的にPodのステータスは正常にもかかわらず、Pod内の業務は異常という現象が発生することがあります。 | |
| サービスを作成する際は、実際のアクセスの必要性に応じて適切なアクセス方式を選択する必要があります。現在は、パブリックネットワークアクセス、クラスター内のみのアクセス、VPCプライベートネットワークアクセス、ホストポートアクセスの4種類をサポートしています。 | デプロイ | 適切でないアクセス方式を選択すると、サービス内外のアクセスロジックが混乱し、リソースの浪費が発生する可能性があります。 | |
| ワークロードの作成の際は、Pod単体のレプリカ数を設定することは避け、ご自身の業務に合わせてノードスケジューリングポリシーを合理的に設定してください。 | 信頼性 | Pod単体のレプリカ数を設定した場合、ノードの異常またはインスタンスの異常が発生した場合、サービスにも異常が生じます。Podのスケジューリングを確実に成功させるため、スケジューリングルールを設定後に、ノードにコンテナのスケジューリング用のアイドルリソースがあることを確実にしてください。 | |
カテゴリー | 評価項目 | タイプ | 影響の説明 | 評価の参照 |
コンテナデータの永続化 | アプリケーションPodのデータストレージについては、実際のニーズに応じて適切なデータボリュームタイプを選択します。 | 信頼性 | ノードの異常が復旧できない場合、ローカルディスク内に存在するデータは復元できませんが、この場合クラウドストレージは極めて高いデータ信頼性を提供することができます。 |
カテゴリー | 評価項目 | タイプ | 影響の説明 | 評価の参照 |
エンジニアリング | CVM、VPC、サブネット、CBSなどのリソースのクォータがお客様のニーズを満たしているかどうか。 | デプロイ | クォータが不足するとリソースの作成に失敗することがあります。自動スケーリングを設定しているユーザーは特に、使用しているクラウドサービスのクォータが十分であることを保障する必要があります。 | |
| クラスターのノード上で、カーネルパラメータ、システム設定、クラスターのコアコンポーネントのバージョン、セキュリティグループ、LB関連パラメータなどをユーザーが任意に変更することは推奨しません。 | デプロイ | TKEクラスター機能の異常またはノード上にインストールしたKubernetesコンポーネントの異常をもたらし、ノードのステータスが利用不可に変わり、アプリケーションをこのノードにデプロイできなくなる可能性があります。 | |
能動的な運用保守 | TKEはさまざまな次元での監視およびアラート機能を提供すると同時に、TCOPが提供する基本的なリソース監視と合わせて、より詳細な指標によるカバーを保証することができます。監視アラートを設定することで、異常の際に速やかにアラートを受信して故障位置の特定を行うことができます。 | 監視 | 監視アラートを設定しないと、コンテナクラスターのパフォーマンスの正常な基準を確立できず、異常が発生した場合に適時にアラートを受信できないため、環境の巡回検査を手動で行う必要があります。 | |
文档反馈