奨励するツール
kubectx
kubectx:スイッチクラスタにアクセスするために使用
kubens:デフォルトの名前空間を切り替えます
kubectl、エイリアス
kubectl
コマンドエイリアス
クラスタ管理関連のコマンド
kubectl get cs
# 查看节点
kubectl get nodes
kubectl get ing pdd --n java
# 不调度
kubectl taint nodes node1 key=value:NoSchedule
kubectl cluster-info dump
kubectl get svc --sort-by=.metadata.creationTimestamp
kubectl get no --sort-by=.metadata.creationTimestamp
kubectl get po --field-selector spec.nodeName=xxxx
kubectl get events --field-selector involvedObject.kind=Service --sort-by='.metadata.creationTimestamp'
参考リンク:
- アプリケーション管理関連
kubectl top pod
kubectl delete deployment,services -l app=nginx
kubectl scale deployment/nginx-deployment --replicas=2
kubectl get svc --all-namespaces=true
- 削除するには、強制
問題は、パラメータが2時にPV / PVCを削除、追加する必要があり、このコマンドを使用して、あります--grace-period=0 --force
- 失敗したすべてのポッドを削除します。
kubectl get po --all-namespaces --field-selector 'status.phase==Failed'
kubectl delete po --field-selector 'status.phase==Failed'
- いくつかのヒント
K8Sは現在のところ同様のドッキングウィンドウ-構成が存在しないdepends_on
依存起動メカニズムを推奨待ち、それが書き換えコマンドミラー。
(ティーチング)経験(トレーニング)によるクラスタ管理
ノード問題
フリーズとの汚点
kubectl taint nodes xx elasticsearch-test-ready=true:NoSchedule
kubectl taint nodes xx elasticsearch-test-ready:NoSchedule-
マスターノード自体が汚染が来るので、コンテナを解放するために私たちをリードするカスタム場合は、上記マスターノードで実行されませんtaint
、我々は注意を払う必要があります!すべてDaemonSet
とKUBE-システム、適切な持参する必要がありますtolerations
。そうしないと、ノードすべてはなしで強制送還されtolerations
ますのでご注意ください、でも、ネットワークプラグイン、KUBE-プロキシ、非常に深刻な影響を含め、コンテナ
taint
tolerations
ペアが存在に対応する、操作者が無差別に使用することができません
NOEXECUTE
tolerations:
- key: "elasticsearch-exclusive"
operator: "Equal"
value: "true"
effect: "NoExecute"
kubectlの汚染ノードCN-shenzhen.xxxx elasticsearch専用=真:NOEXECUTE
NOEXECUTEは、操作は非常に危険です、あなたが対応するシステムコンポーネントの設定tolerationsがあることを確認する必要があり、すぐに条件に耐えるように強制送還満足ポッドではありません。
特別な注意Exists
この演算子が無効である、それがなければなりませんEqual
NoSchedule
tolerations:
- key: "elasticsearch-exclusive"
operator: "Exists"
effect: "NoSchedule"
- key: "elasticsearch-exclusive"
operator: "Equal"
value: "true"
effect: "NoExecute"
kubectlの汚染ノードCN-shenzhen.xxxx elasticsearch専用=真:NoSchedule
これは、このディスパッチの上に行くしないようにしようしているが、実際にはまだそこにいたポッドが駆け上がりました
Exists
そして、Exists
自由に使用する、ではない非常に多くの影響
これは、同じキーが複数の同時効果できること言及する価値があります
Taints: elasticsearch-exclusive=true:NoExecute
elasticsearch-exclusive=true:NoSchedule
その他の参照リンク:
正しいノードを単離する工程
# 驱逐除了ds以外所有的pod
kubectl drain <node name> --ignore-daemonsets
kubectl cordon <node name>
この時間は、コマンドを実行するノードを取得し、状態になり
node.xx Ready,SchedulingDisabled <none> 189d v1.11.5
遂に
kubectl delete <node name>
適切なステップのノードを維持
kubectl drain <node name> --ignore-daemonsets
kubectl uncordon <node name>
ディスクノード圧(DiskPressure)
--eviction-hard=imagefs.available<15%,memory.available<300Mi,nodefs.available<10%,nodefs.inodesFree<5%
アリクラウドへkubelet起動ディスク指定圧力は、例えば、imagefs.available<15%
時間の15%未満の読み書き層容器は、ノードが追い出されることを意味する。ノード追放結果がこの状況DiskPressureを生成し、ノードでありますもはや問題が解決されるまで、あなたはディレクトリを削除することはできませんので、コンテナのホームディレクトリを使用して、ノードは、この問題は、致命的になる場合。任意のミラーリング、ディスクを実行していないが、実際の蓄積のこれらのディレクトリのホスト、ノードにつながることができます彼らは、追放されました。
だから、通常は良い何かがコンテナ内であなたの舌をかむ書くために良い習慣を維持するために(ファイルが書かれている容器は短命-ストレージを取ることができ、一時的な貯蔵ポッドはあまり追放されます)、そして可能な限り非国家型容器、ストレージの慎重な選択、より多くの利用このストレージホストパスを使用していません
条件は本当に、涙の感情のようなものを発生した場合。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FreeDiskSpaceFailed 23m kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 5182058496 bytes, but freed 0 bytes
Warning FreeDiskSpaceFailed 18m kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 6089891840 bytes, but freed 0 bytes
Warning ImageGCFailed 18m kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 6089891840 bytes, but freed 0 bytes
Warning FreeDiskSpaceFailed 13m kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 4953321472 bytes, but freed 0 bytes
Warning ImageGCFailed 13m kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 4953321472 bytes, but freed 0 bytes
Normal NodeHasNoDiskPressure 10m (x5 over 47d) kubelet, node.xxxx1 Node node.xxxx1 status is now: NodeHasNoDiskPressure
Normal Starting 10m kube-proxy, node.xxxx1 Starting kube-proxy.
Normal NodeHasDiskPressure 10m (x4 over 42m) kubelet, node.xxxx1 Node node.xxxx1 status is now: NodeHasDiskPressure
Warning EvictionThresholdMet 8m29s (x19 over 42m) kubelet, node.xxxx1 Attempting to reclaim ephemeral-storage
Warning ImageGCFailed 3m4s kubelet, node.xxxx1 failed to garbage collect required amount of images. Wanted to free 4920913920 bytes, but freed 0 bytes
参考リンク:
彪高いCPUノード
(コンテナ・GC /画像GC)GC中にノードがあるかもしれない 、 とdescribe node
見て。私はかつてこのような状況、最後のノード上のはるかに少ないの容器が、また、押し下げビットに遭遇しました
Events:
Type Reason Age From Message
---- ------ ---- ----
Warning ImageGCFailed 45m kubelet, cn-shenzhen.xxxx failed to get image stats: rpc error: code = DeadlineExceeded desc = context deadline exceeded
参考:
オブジェクト
下
ポッドは、頻繁に再起動します
そこさまざまな理由であり、一般化することはできません
リソースにアクセス制限設定値
上限を増やすか、アプリケーションをチェック
準備/ライブネス接続は拒否しました
レディネスチェックの失敗は再起動されますが、Readiness
チェックが失敗したノード自体が過負荷状態にあれば、必ずしもアプリケーションの問題ではない、またそこにタイムアウトや接続は拒否されます
ノード上でこの問題を解決するために、
ポッド追放(追い出さ)
- ノードプラスステインリードポッド追放
-
エフェメラルストレージは追放制限を超え
- EmptyDirの使用量は、このポッドが強制送還され、彼のSIZELIMITを超えます
- 容器の使用は、(非オーバーレイ・ゾーニングがない場合imagefsを含む、ログ)をポッドが追放され、彼の限界を超え
- ポッドすべての容器の限界でポッド上の総使用量(全emptydir及び容器)のローカルの一時記憶した後、排出さポッド
エフェメラルストレージが一時的ポッドを格納するために使用されます。
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "3Gi"
追放された後、ノードは、まだ記述コマンドを使用して、あなたは追放され、歴史的な理由を見ることができ、POを取得を通して見ることができます
メッセージ:一時的なストレージ:ノードがリソースに低かったです。容器CODISプロキシは0、その要求を超える10619440Kiを、使用していました。
参考:
kubectl execがコンテナに入ることができませんでした
、実際には。ディスプレイが実行して、この時間コンテナと正常ではないがCODISサーバ、準備、および設定なしのヘルスチェックを構築する場合。しかし、ポッドの説明を取得するとき、私は、この問題が発生しました。
~ kex codis-server-3 sh
rpc error: code = 2 desc = containerd: container not found
command terminated with exit code 126
解決策:このポッドを削除し、コンフィギュレーションlivenessProbe
仮想ホスト名のポッド
Deployment
派生ポッド、virtual host name
それがありますpod name
。
StatefulSet
派生ポッド、virtual host name
市は<pod name>.<svc name>.<namespace>.svc.cluster.local
と比べDeployment
、いくつかのより定期的に表示されます。そして、他のポッドのアクセスをサポート
別のCrashbackoff後のポッド
Crashbackoff
さまざまな理由があります。
サンドボックス(FailedCreateSandBox)を作成し、主にネットワークプラグの問題CNI、失敗しました
大きすぎること、中国の特色ある社会主義の問題がある、プルもミラーリング、遅いプル
コンテナは雪崩の流れが生じ、高すぎるによって複雑にすることができるもあります。
例えば、突然発生したトラフィックのピークラッシュが順番に、内部崩壊につながったABC、3個のコンテナがありCrashbackoff
、その後、されservice
て取り除かは、紀元前の残りの部分は別のクラッシュの後、そんなにトラフィックを運ぶことができず、サイトはアクセスできません最終的には。この場合、並行性の高いウェブサイト+非効率的なWebコンテナでより一般的。
コードが変化しない場合には、最適解は、コピーの数を増加させることであり、HPA、動的伸縮能力を付加します。
配備します
MinimumReplicationUnavailable
場合deploy
SecurityContextがの設定が、API-サーバーを拒否し、このケースになり、コンテナAPIサーバの内部は削除SecurityContextDeny
ブートパラメータを。
特に参照入場コントローラを使用します
サービス
何が起こるか、我々はサービスを構築しましたが、該当するPOはありませんか?
要求は、要求のタイムアウトするまで、何の応答行われていない場合には
参照
サービス接続は拒否します
理由があるかもしれません
- ポッドは、ポッドを要求する準備ができていないreadinessProbeを、提供されていません
- KUBE-プロキシがダウンしている(KUBE-プロキシは、要求を転送するための責任があります)
- ネットワークの過負荷
無負荷分散サービスません
使用するかどうかを確認してくださいheadless service
。headless service
自動的にロード・バランシングはありません...
kind: Service
spec:
# clusterIP: None的即为`headless service`
type: ClusterIP
clusterIP: None
自分の仮想IPのないパフォーマンスのサービス固有の、nslookupコマンドのIPは、すべてのポッドになりますが、ピングIP最初のポッドが表示された場合にのみ
/ # nslookup consul
nslookup: can't resolve '(null)': Name does not resolve
Name: consul
Address 1: 172.31.10.94 172-31-10-94.consul.default.svc.cluster.local
Address 2: 172.31.10.95 172-31-10-95.consul.default.svc.cluster.local
Address 3: 172.31.11.176 172-31-11-176.consul.default.svc.cluster.local
/ # ping consul
PING consul (172.31.10.94): 56 data bytes
64 bytes from 172.31.10.94: seq=0 ttl=62 time=0.973 ms
64 bytes from 172.31.10.94: seq=1 ttl=62 time=0.170 ms
^C
--- consul ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.170/0.571/0.973 ms
/ # ping consul
PING consul (172.31.10.94): 56 data bytes
64 bytes from 172.31.10.94: seq=0 ttl=62 time=0.206 ms
64 bytes from 172.31.10.94: seq=1 ttl=62 time=0.178 ms
^C
--- consul ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.178/0.192/0.206 ms
普通のタイプ:CLUSTERIPサービス、nslookupコマンドは、IPサービスを所有します
/ # nslookup consul
nslookup: can't resolve '(null)': Name does not resolve
Name: consul
Address 1: 172.30.15.52 consul.default.svc.cluster.local
ReplicationController更新されません
ReplicationControllerアップデートを適用するために使用されるが、ではないkubectl rolling-update
が、このディレクティブはまた、廃止によって置き換えられるkubectl rollout
ので、使用すべきでkubectl rollout
更新または少し怠惰の手段として、そのファイルを適用し、POを削除します。
それを展開使用してみてください。
StatefulSetの更新に失敗しました
StatefulSetがあるかどうかを見て、一つずつ更新されCrashbackoff
た容器、コンテナが立ち往生このアップデートの原因である可能性があり、それを削除することができます。
高度なスケジューリング
ターゲット・ノード上の親和性ノードランニングの使用を確認してください
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: elasticsearch-test-ready
operator: Exists
参考リンク:
使用する抗親和性は、各ノードは、同じアプリケーションを実行することを保証します
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: 'app'
operator: In
values:
- nginx-test2
topologyKey: "kubernetes.io/hostname"
namespaces:
- test
許容実行
マスター画像の上で実行するように強制所望であれば、汚れたマスターノードは、適切な染色を許容する必要があるため、マスタノードは、一般的なイメージを許可しない理由。
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
- effect: NoSchedule
key: node.cloudprovider.kubernetes.io/uninitialized
operator: Exists
アリは、発行Kubernetesを曇らせます
デフォルトの進入を変更
バランスをロードするために、新しいタイプのSVCの進入ポイントを作成し、それを変更するkube-system
時にnginx-ingress-controller
起動パラメータ。
- args:
- /nginx-ingress-controller
- '--configmap=$(POD_NAMESPACE)/nginx-configuration'
- '--tcp-services-configmap=$(POD_NAMESPACE)/tcp-services'
- '--udp-services-configmap=$(POD_NAMESPACE)/udp-services'
- '--annotations-prefix=nginx.ingress.kubernetes.io'
- '--publish-service=$(POD_NAMESPACE)/<自定义svc>'
- '--v=2'
ロードバランサIPサービスがされていません
特定のパフォーマンスは、外部-IPは保留中に表示されています。
~ kg svc consul-web
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
consul-web LoadBalancer 172.30.13.122 <pending> 443:32082/TCP 5m
この問題はアリババクラウドプロバイダーは、関連するこのコンポーネントは、cloud-controller-manager
3つの要素があり、彼らは間違って行く、と、私は問題置くことができ、内部選挙の主、必要pod
に削除、ちょうど罰金を。
クリーンアップStatefulsetダイナミックPVC
現時点では、アリ雲Statefulset
PVCの動的な使用がNASです。
- この店では、最初の容器がゼロ、または全体になりますコピーする必要があり
Statefulset
、削除します。 - PVCを削除します
- NASは、上記の任意のサーバーにマウントし、ディレクトリPVC NAS対応を削除します。
v1.12.6-aliyun.1少なく割り当てられたメモリノードへのアップグレード後
各ノードのバージョンは、ポッドを分配するための(Nはノードの数である)より少ないクラスタ全体に相当1GI、N GB予約しました。
ノードは、4G、ポッド要求3Gの場合は、非常に簡単に強制送還されます。
これは、ノードの仕様を増やすことを提案しました。
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.6-aliyun.1", GitCommit:"8cb561c", GitTreeState:"", BuildDate:"2019-04-22T11:34:20Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
追加新しいノードがNetworkUnavailableに表示されます
RouteControllerは、ルートの作成に失敗しました
あれば、kubernetesイベントを見て
timed out waiting for the condition -> WaitCreate: ceate route for table vtb-wz9cpnsbt11hlelpoq2zh error, Aliyun API Error: RequestId: 7006BF4E-000B-4E12-89F2-F0149D6688E4 Status Code: 400 Code: QuotaExceeded Message: Route entry quota exceeded in this route table
この問題はの手の届かないために発生カスタムルートVPCエントリの制限は、デフォルトは48で、私たちが調達する必要があるvpc_quota_route_entrys_num
クォータを
(関連アプリケーションをスケジュールする)参照: