ドキュメントを正しく理解したかどうかを知りたいだけです。
4つのレプリカを持つDeploymentバージョン1.7.9で構成されたnginxサーバーがあるとします。
apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 4
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
次に、イメージをバージョン1.9.1に更新します。
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
kubectl get pods私は次のことを確認します。
> kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-2100875782-c4fwg 1/1 Running 0 3s
nginx-2100875782-vp23q 1/1 Running 0 3s
nginx-390780338-bl97b 1/1 Terminating 0 17s
nginx-390780338-kq4fl 1/1 Running 0 17s
nginx-390780338-rx7sz 1/1 Running 0 17s
nginx-390780338-wx0sf 1/1 Running 0 17s
1.9.1の2つの新しいインスタンス（c4fwg、vp23q）が、1.7.9バージョンの3つのインスタンスとしばらくの間共存を開始しました。
この時点でサービスに対して行われた要求はどうなりますか？すべての新しいポッドが利用可能になるまで、すべてのリクエストは古いポッドに送られますか？または、リクエストは新しいポッドと古いポッドの間で負荷分散されていますか？
最後のケースでは、この動作を変更して、すべての新しいポッドが開始されるまで、すべてのトラフィックが古いバージョンに送られるようにする方法はありますか？
「リクエストはどうなるか」に対する答えは、サービス内のセレクターに一致するすべてのポッドでラウンドロビンされるため、すべてのポッドがトラフィックを受信するということです。kubernetesは、これをバグではなく機能と見なしていると思います。
古いポッドに向かうトラフィックについての答えは、2つの方法で答えることができます。おそらく、デプロイメントは、新しいポッドを展開するスタイルに適していない可能性があります。もう1つの答えは、サービス内のポッドセレクターを更新して、「このサービスはポッド1.7.9用です」をより正確に記述できることです。これにより、そのサービスが「古い」ポッドに固定され、1.9の1つだけでも固定されます。 .1ポッドが開始され、準備ができました。セレクターを更新して、「このサービスはポッド1.9.1用です」と指定できます。
これらすべてが手作業でやりすぎだと感じた場合は、ポッドセレクターを使用するよりもきめ細かい制御が可能な中間トラフィックマネージャーがたくさんあります。または、Spinnakerなどの正式なロールアウト製品を検討してください。説明したばかりです（もちろん、Spinnakerを動作させることができると仮定します。幸運を祈ります）
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加