クォータノードとカーネルパラメータの調整
パブリッククラウド上のKubernetesクラスタの場合、非常に大規模なコンテナのクォータ後にクラウドプラットフォーム上で事前にクォータを増やすために、問題とニーズが発生しました。これらは、クォータを増やす必要が含ま
- 仮想マシンの数
- vCPUの数
- ネットワーク内でIPアドレスの数
- パブリックネットワークIPアドレスの数
- セキュリティグループの数
- ルーティングテーブルの数
- 永続ストレージ・サイズ
マスターノードのノード構成の増加に伴ってGCE参照ノード。
- 1-5ノード：N1-標準1
- 6-10ノード：N1-標準-2
- 11-100ノード：N1-標準-4
- 101から250ノード：N1-標準-8
- 251から500ノード：N1-標準16
- 500以上のノード：N1-標準32
参考アリクラウド構成：
| ノードのスケール | マスター仕様 |
|---|---|
| ノード1-5 | 4C8G（2C4G推奨されません） |
| 6-20ノード | 4C16G |
| 21から100個のノード | 8C32G |
| 100-200ノード | 16C64G |
/etc/sysctl.confのカーネル設定オプションを増やします：
fs.file-max=1000000
# max-file 表示系统级别的能够打开的文件句柄的数量， 一般如果遇到文件句柄达到上限时，会碰到
"Too many open files"或者Socket/File: Can’t open so many files等错误。
# 配置arp cache 大小
net.ipv4.neigh.default.gc_thresh1=1024
# 存在于ARP高速缓存中的最少层数，如果少于这个数，垃圾收集器将不会运行。缺省值是128。
net.ipv4.neigh.default.gc_thresh2=4096
# 保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前，允许记录数超过这个数字 5 秒。缺省值是 512。
net.ipv4.neigh.default.gc_thresh3=8192
# 保存在 ARP 高速缓存中的最多记录的硬限制，一旦高速缓存中的数目高于此，垃圾收集器将马上运行。缺省值是1024。
以上三个参数，当内核维护的arp表过于庞大时候，可以考虑优化
net.netfilter.nf_conntrack_max=10485760
# 允许的最大跟踪连接条目，是在内核内存中netfilter可以同时处理的“任务”（连接跟踪条目）
net.netfilter.nf_conntrack_tcp_timeout_established=300
net.netfilter.nf_conntrack_buckets=655360
# 哈希表大小（只读）（64位系统、8G内存默认 65536，16G翻倍，如此类推）
net.core.netdev_max_backlog=10000
# 每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
关于conntrack的详细说明：https://testerhome.com/topics/7509
fs.inotify.max_user_instances=524288
# 默认值: 128 指定了每一个real user ID可创建的inotify instatnces的数量上限
fs.inotify.max_user_watches=524288
# 默认值: 8192 指定了每个inotify instance相关联的watches的上限
Etcd
-
Etcdビルド高可用性クラスタクラスタノードがetcdのサイズを大きくするとき、それは自動的に増やすことができます
現在のソリューションは、オペレータがCoreOSを狙っ導入し、etcdクラスタを構築するetcd演算子を使用することである
Kubernetesを展開し、コントローラアプリケーションを意識状態であるフレームアプリケーション管理、との複合体状態を簡略化し
、自動的にAPIを作成するために、構成管理応用例。etcdオペレータは次の機能があります。
- ceate /破壊：自動的に展開し、人間の介入なしに、追加の構成etcdクラスタを、削除します。
- サイズを変更：クラスタは、動的etcdスケーリング能力を実装することができます。
- バックアップ：データのバックアップと復旧・復興クラスタのサポートetcdクラスタ
- アップグレード：中断のないサービスアップグレードetcdクラスタを実現することができます。
-
設定etcd使用SSD SSDストレージ
-
etcdの提供--quota-バックエンドバイトは、記憶制限を増加させました。デフォルト値は2Gです
-
ストレージKUBE-apiserverイベントの別々のクラスタを構成するEtcd必要。
ミラープル構成
ドッカー設定
- セット最大並列実行ダウンロード= 10
各プル動作の同時ダウンロード設定の最大数は、プルミラーの効率を改善するために、デフォルト値は3です。 - 使用SSDストレージ。
- -o /opt/preloaded_docker_images.tarして保存ポーズ画像、例えばドッカー画像をプリロード
ドッカー画像負荷-i /opt/preloaded_docker_images.tarは
それぞれ、プルネットワーク帯域幅を低減するために、ミラーPODポーズ、ポーズ画像を引っ張る開始しますノード予圧ポーズ画像。
Kubelet配置
- --serialize像引っ張るを提供= falseを
設定オプションのシリアルプルミラー、デフォルト値はtrueで、falseが並行性を増加させるように構成することができます。しかし、ドッキングウィンドウデーモンの場合
、バージョンは1.9未満であり、かつ用途aufsのストレージは、このオプションを変更することはできません。 - 提供--imageプル進捗期限= 30は、
ミラーを引き出すように構成されています。量は、ミラーのタイムアウトを引くために必要な大規模な増加のための1分のデフォルト値は、。 - ポッドKubeletを実行する許可された最大単一ノードの数： - MAX-ポッド= 110（必要に応じて110が設定されてもよいデフォルト）
ミラーレジストリP2P配信
kube-api-server 配置
：ノード> = 3000、以下のように推奨設定のノード番号
--max-要求-機内= 3000
--max-変異機内-要求-1000 =
ノード1000--3000内のノードの数は、推奨される設定は次のように
--max-requests-inflight=1500 --max-mutating-requests-inflight=500 メモリ構成オプションとノード番号との関係は、単位はMBです。
--target-ram-mb=node_nums * 60
ポッドの設定
ポッドを実行しているときも、のようないくつかのベストプラクティスに従うように注意を払う必要があります。
-
コンテナのリソース要求と制限、特にいくつかの基本的なサービス、プラグインを設定し
spec.containersを[]。Resources.limits.cpuの
spec.containers []。Resources.limits.memory
spec.containers []。Resources.requests.cpuの
spec.containers []は.resources.requests.memory
spec.containers []。resources.limits.ephemeralストレージ
spec.containers []。resources.requests.ephemeral記憶
K8Sにおいて、異なるポッドおよびポッドに基づく限界が配置要求であります別のカテゴリに分けたQoS：
-保証
-バースト可能
-にBestEffortは
ない十分なリソースが利用可能なマシンは、kubeletが移行されますQoSのレベルの区分に応じたポッドを追放します。優先順位の除名：保証にBestEffort>バースト可能> -
重要なアプリケーションはnodeAffinity、podAffinity podAntiAffinityと保護を使用し、
大きく異なるスケジューリングは、ノードを分散させました。設定例のKUBE-DNS：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution: - weight: 100 labelSelector: matchExpressions: - key: k8s-app operator: In values: - kube-dns topologyKey: kubernetes.io/hostname - コンテナ（例えば、配置、StatefulSet、DaemonSet、ジョブなど）を管理するためにコントローラを使用すること
Kube-scheduler 配置
- 提供--kube-API-QPS = 100
デフォルト値は50であります
KUBEコントローラマネージャ構成
- 提供--kube-API-QPS = 100
デフォルト値は20であります - 提供--kube-API-バースト= 100
デフォルト値は30であります