第3章 ホストの推奨プラクティス

OpenShift Container Platform インフラストラクチャーで、Pod トラフィックの他に最も使用されるデータパスは OpenShift Container Platform マスターホストと etcd 間のデータパスです。OpenShift Container Platform API サーバー (マスターバイナリーの一部) は、ノードのステータス、ネットワーク設定、シークレットなどについて etcd に確認します。

以下を実行してこのトラフィックパスを最適化します。

OpenShift Container Platform マスターは、CPU 負荷を軽減するためにデシリアライズされたバージョンのリソースを積極的にキャッシュします。ただし、1000 Pod 未満の小規模なクラスターでは、このキャッシュにより、無視できる程度の CPU 負荷を削減するために大量のメモリーが浪費される可能性があります。デフォルトのキャッシュサイズは 50,000 エントリーですが、リソースのサイズによっては 1 から 2 GB メモリーを占有する程度まで拡大する可能性があります。キャッシュのサイズは、/etc/origin/master/master-config.yaml で以下の設定を使用して縮小できます。

kubernetesMasterConfig:
  apiServerArguments:
    deserialization-cache-size:
    - "1000"

API サーバーに送信されるクライアント要求または API 呼び出しの数は、1 秒あたりクエリー (QPS: Queries Per Second) の値によって決まり、API サーバーで処理できる同時要求の数は、maxRequestsInFlight 設定によって決まります。クライアントが QPS レートを超えることのできる要求の数は、バースト値によって異なります。これは、バースト性があり、不規則な数の要求を実行できるアプリケーションに役立ちます。とくに大容量または高密度のクラスターなど、API サーバーが処理するる同時要求が多数ある場合は、要求の応答時間のレイテンシーが長くなる可能性があります。Prometheus の apiserver_request_count レートメトリクスを監視し、maxRequestsInFlight と QPS を適宜調整することが推奨されます。

API サーバーの CPU およびメモリーの消費としてデフォルト値を変更すると、適切なバランスが必要となります。また、追加の要求を並行して処理する際に etcd IOPS が増えます。また、監視されていない要求が多くなると、60 秒の固定タイムアウトの後にキャンセルされ、クライアントが再試行を開始するため、API サーバーに過負荷がかかる可能性がある点に注意してください。

API サーバーシステムで十分な CPU およびメモリーリソースが利用できることを前提とすると、API サーバー要求のオーバーロードする問題は、上記の要素を考慮し、 *_/etc/origin/master/master-config.yaml で maxRequestsInFlight、API qps およびバースト値を引き上げることによって安全に軽減することができます。

masterClients:
  openshiftLoopbackClientConnectionOverrides:
    burst: 600
    qps: 300
servingInfo:
  maxRequestsInFlight: 500