Kubernetes管理の経験

奨励するツール

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'

参考リンク:

  1. kubernetesノードは、uncordonコルドン、ドレインを維持します
  • アプリケーション管理関連
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-プロキシ、非常に深刻な影響を含め、コンテナ

tainttolerationsペアが存在に対応する、操作者が無差別に使用することができません

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

その他の参照リンク:

  1. Kubernetes(汚れや寛容)の汚点と寛容
  2. kubernetesスケジューリング機構

正しいノードを単離する工程

# 驱逐除了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

参考リンク:

  1. 立ち退きシグナル
  2. 図10はあなたの深い理解ドッカーコンテナやミラーを取ります

彪高い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

参考:

kubeletソースコード解析:ガベージコレクト

オブジェクト

ポッドは、頻繁に再起動します

そこさまざまな理由であり、一般化することはできません

リソースにアクセス制限設定値

上限を増やすか、アプリケーションをチェック

準備/ライブネス接続は拒否しました

レディネスチェックの失敗は再起動されますが、Readinessチェックが失敗したノード自体が過負荷状態にあれば、必ずしもアプリケーションの問題ではない、またそこにタイムアウトや接続は拒否されます

ノード上でこの問題を解決するために、

ポッド追放(追い出さ)
  1. ノードプラスステインリードポッド追放
  2. エフェメラルストレージは追放制限を超え

    1. EmptyDirの使用量は、このポッドが強制送還され、彼のSIZELIMITを超えます
    2. 容器の使用は、(非オーバーレイ・ゾーニングがない場合imagefsを含む、ログ)をポッドが追放され、彼の限界を超え
    3. ポッドすべての容器の限界でポッド上の総使用量(全emptydir及び容器)のローカルの一時記憶した後、排出さポッド

エフェメラルストレージが一時的ポッドを格納するために使用されます。

resources:
       requests: 
           ephemeral-storage: "2Gi"
       limits:
           ephemeral-storage: "3Gi"

追放された後、ノードは、まだ記述コマンドを使用して、あなたは追放され、歴史的な理由を見ることができ、POを取得を通して見ることができます

メッセージ:一時的なストレージ:ノードがリソースに低かったです。容器CODISプロキシは0、その要求を超える10619440Kiを、使用していました。

参考:

  1. Kubernetesポッド短命-ストレージ構成
  2. コンテナのための計算リソースの管理
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

場合deploySecurityContextがの設定が、API-サーバーを拒否し、このケースになり、コンテナAPIサーバの内部は削除SecurityContextDenyブートパラメータを。

特に参照入場コントローラを使用します

サービス

何が起こるか、我々はサービスを構築しましたが、該当するPOはありませんか?

要求は、要求のタイムアウトするまで、何の応答行われていない場合には

参照

  1. リソースの処理・アウト・オブ・設定
サービス接続は拒否します

理由があるかもしれません

  1. ポッドは、ポッドを要求する準備ができていないreadinessProbeを、提供されていません
  2. KUBE-プロキシがダウンしている(KUBE-プロキシは、要求を転送するための責任があります)
  3. ネットワークの過負荷
無負荷分散サービスません

使用するかどうかを確認してくださいheadless serviceheadless 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

参考リンク:

  1. 高度なスケジューリング・イン・kubernetes
  2. kubernetes-scheulder-アフィニティ

使用する抗親和性は、各ノードは、同じアプリケーションを実行することを保証します

      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-manager3つの要素があり、彼らは間違って行く、と、私は問題置くことができ、内部選挙の主、必要podに削除、ちょうど罰金を。

クリーンアップStatefulsetダイナミックPVC

現時点では、アリ雲StatefulsetPVCの動的な使用がNASです。

  1. この店では、最初の容器がゼロ、または全体になりますコピーする必要がありStatefulset、削除します。
  2. PVCを削除します
  3. 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クォータを

(関連アプリケーションをスケジュールする)参照:

  1. 健康診断と治療サービスのKubernetesが依存しています
  2. どのようにkubernetes解決サービスがそれに依存しますか?
  3. Kubernetes道1 - Javaのアプリケーションリソースの制約の神話
  4. ノード上の制御CPUの経営方針
  5. システムデーモン引当金の計算リソース
  6. リソースの処理・アウト・オブ・設定

おすすめ

転載: yq.aliyun.com/articles/703971