Kubernetes を使用する際に注意すべき落とし穴

Kubernetes を実践する過程で、ギャップを埋める経験を積んできました。簡単に要約して皆さんと共有したいと思います。

Kubernetes の準備や使用を考えている方にとって、これが役立つことを願っています。

ローリングアップグレード: 更新が遅すぎる

デフォルトでは、ローリング アップグレードは 1 つずつ実行されます。更新が必要なポッドが数十または数百あり、準備状況の検出も必要な場合、プロセス全体の速度は遅くなります。より多くの Kubernetes 技術専門家とコミュニケーションを取りたい場合は、私の WeChat liyingjiese を追加し、「グループに参加」と記入してください。当グループには、世界中の大手企業のベストプラクティスと業界の最新トレンドが毎週掲載されています。

解決：

ローリングアップデート:
   maxSurge: 20% #ローリング更新あたりのインスタンス数
   maxUnavailable: 10% #更新プロセス中に利用不可にできるインスタンスの数

準備状況の検出 - ロスレス更新

通常、サービスを再起動すると、しばらくの間、通常のサービスを提供できなくなります。

このプロセス中に受信リクエスト トラフィックを回避するために、準備状況検出を使用して、サービスがリクエストを正常に受信して処理する準備ができているかどうかを検出できます。

 ......
        準備プローブ:
          httpGet:
            ホスト: api.xxx.com
            パス： /
            ポート: 80
          initialDelaySeconds: 3 # 最初の検出はコンテナが起動してから3秒後に開始されます
          periodSeconds: 60 # 60秒ごとにチェック
          timeoutSeconds: 3 # http 検出リクエストのタイムアウト
          successThreshold: 1 # 1回の成功が検出されると、サービスは「準備完了」とみなされます
          failureThreshold: 1 # 1つの障害が検出された場合、サービスは「準備ができていない」とみなされます
......

準備検出: 完全な麻痺

準備状況の検出は諸刃の剣です。適切に使用しないと、サービスの完全な停止など、大きな問題に簡単につながる可能性があります。

上記の準備状況チェック構成には抜け穴がたくさんあることがわかります。

たとえば、タイムアウトの場合、同時実行性が高いと、リクエストを処理できず、個々のサービスが検出リクエストを簡単にタイムアウト (504) し、すぐに準備ができていないと見なされる可能性があります。その後、トラフィックは他のサービスに転送され、すでに高負荷になっている他のサービスでも同じ状況が発生し、悪循環が生じます。すぐに、すべてのサービスが準備ができていないとみなされ、完全な麻痺状態に陥ります。

解決策:タイムアウト期間を長くし、失敗回数を増やします。

再展開します。これは、サービスがクラッシュする原因となったエラーまたはその他の異常が原因である可能性があります。つまり、ユーザーがまだサービスをリクエストしようとしている間に再起動する必要があります。正常に起動して準備完了状態になることができず、すべてのサービスが準備完了ではないことに驚かれることでしょう。同じ理由で、サービスの起動プロセスは一度に開始されるのではなく、バッチで開始されます。その結果、各サービス バッチは起動後にトラフィックを保持できず、悪循環が形成され、完全な麻痺が発生します。

解決策:準備チェックを削除してから再デプロイします。

瞬間ピークの自動拡大

POD の自動拡張は使いやすいですが、拡張インジケータ (CPU、メモリなど) が 50% を超えるなど高く設定されすぎると、トラフィックが突然 2 倍になったときに Pod を拡張する時間がなく、サービスがすぐにタイムアウトまたはハングアップしてしまいます。

解決策:インジケーターをできるだけ小さい値に設定し、以前のトラフィックに基づいて参照評価を行い、トラフィックが 2 倍、3 倍、さらには 5 倍に増加した場合でも耐えられることを確認します。

自動スケーリング: 早期拡張

通常、ノードの自動スケーリングは、Pod が自動的に拡張されるときに十分なリソースがあるかどうかによって決まります。しかし、突然の予定されたトラフィックのピークを経験するビジネスの場合、このタイプのスケーリングは明らかに遅すぎます。ピークから10分後にマシンを拡張すると、トラフィックがすでに最低レベルに戻っており、マシンがまったく役に立たないということはよくあります。さらに、トラフィック損失は、ビジネス属性の急激な低下によるものでしょうか、それとも時期尚早な容量拡張によるものでしょうか。

解決策:自社のビジネスに合わせて、過去のトラフィック量やプロモーション時間を参考にしてパターンを見つけ、事前にまたはスケジュールに従って自動拡張をトリガーします。

コンテナ内でゾンビプロセスが実行中

これは、Docker の古いバージョン (<1.13) における既知の問題です。いくつかのコンテナが起動すると、機能していないプロセス (ps aux | grep defunct) が表示され、その数が増加します。これらのプロセスはゾンビ プロセスと呼ばれ、メモリ リークを引き起こす可能性があります。コンテナを再起動しない限り、それらを強制終了することはできません。

解決策: tini

クラスターからノードを削除する

ノードを安全に削除するにはどうすればよいですか?あなたのビジネス、さらには Kube システムのものは、このノードにデプロイされます。

解決策: kubectl dock を使用して、まずノード上の Pod を他のノードに移動してから、それらをノードから移動します。