次のようなKubernetesの展開があります(名前やその他のものを '....'に置き換えます):
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "3"
kubernetes.io/change-cause: kubectl replace deployment ....
-f - --record
creationTimestamp: 2016-08-20T03:46:28Z
generation: 8
labels:
app: ....
name: ....
namespace: default
resourceVersion: "369219"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/....
uid: aceb2a9e-6688-11e6-b5fc-42010af000c1
spec:
replicas: 2
selector:
matchLabels:
app: ....
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: ....
spec:
containers:
- image: gcr.io/..../....:0.2.1
imagePullPolicy: IfNotPresent
name: ....
ports:
- containerPort: 8080
protocol: TCP
resources:
requests:
cpu: "0"
terminationMessagePath: /dev/termination-log
dnsPolicy: ClusterFirst
restartPolicy: Always
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 2
observedGeneration: 8
replicas: 2
updatedReplicas: 2
私が観察している問題は、Kubernetesが同じノードに両方のレプリカを配置することです(2つを要求した展開で)。そのノードがダウンすると、両方のコンテナーが失われ、サービスがオフラインになります。
Kubernetesにしたいことは、コンテナが同じタイプの同じノードでコンテナが重複しないようにすることです-これはリソースを消費するだけで、冗長性を提供しません。展開、レプリカセット、ノードなどに関するドキュメントを調べましたが、Kubernetesにこれを行うように指示するオプションが見つかりませんでした。
Kubernetesに、コンテナに必要なノード全体の冗長性を伝える方法はありますか?
編集:ラベルが機能するかどうかわかりません。ラベルは、ローカルリソース(SSD)などにアクセスできるようにノードの実行場所を制限します。ノードがオフラインになってもダウンタイムが発生しないようにするだけです。
Affinity/Anti-Affinity Selectorsを探していると思います。
Affinityはポッドを同じ場所に配置するためのものであるため、たとえば、Webサイトがキャッシュと同じホストでスケジュールを試行するようにします。一方、反アフィニティは反対であり、ルールのセットに従ってホストでスケジュールしないでください。
だからあなたがやっていることについては、この2つのリンクを詳しく見ていきます: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#never-co-located-同じノード内
https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure
その展開用のサービスを作成する場合、before前述の展開を作成すると、Kubernetesはノードにポッドを分散します。この動作はスケジューラから発生し、ベストエフォートベースで提供され、両方のノードで十分なリソースが利用可能であることを前提としています。
Kubernetesドキュメント( Managing Resources )から:
最初にサービスを指定することをお勧めします。これにより、スケジューラは、展開などのコントローラーによって作成されたサービスに関連付けられたポッドを拡散できるようになります。
また関連: 構成のベストプラクティス-サービス 。
ノードがダウンすると、そのノードで実行されているポッドは別のノードで自動的に再起動されます。
実行する場所を正確に指定し始めると、実際にはKubernetesの機能を失い、別のノードで再スケジュールすることになります。
したがって、通常は、Kubernetesにその処理を実行させるだけです。
ただし、特定のローカルボリュームタイプなどの要件のために、特定のノードでポッドを実行するための有効な要件がある場合は、以下を読んでください。
Antoine Cottenがあなたの展開にサービスを使用することに同意します。何らかの理由で特定のノードで1つのポッドが死んでいる場合、サービスは常に新しいポッドを作成することにより、常にサービスを維持します。ただし、デプロイメントをすべてのノードに配布する場合は、ポッドマニフェストファイルでポッドのアンチアフィニティを使用できます。 gitlabページ に例を示します。これは Kubernetesブログ にもあります。便宜上、ここでも例を示します。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: gcr.io/google_containers/nginx-slim:0.8
ports:
- containerPort: 80
この例では、各デプロイメントにappというラベルがあり、このラベルの値はnginxです。ポッド仕様では、1つのノードに2つの同じポッド(app:nginxというラベル)を持つように制限するpodAntiAffinityがあります。 1つのノードに複数のデプロイメントを配置する場合は、podAffinityを使用することもできます。
おそらくDaemonSet
の方がうまくいくでしょう。特定のノードでポッドを実行し、重複を避けるために、DaemonStets
でnodeSelector
を使用しています。