1.はじめに
DaemonSetは、各ノードでポッドを実行することを保証します。新しいノードが追加されると、ポッドは新しく追加されたノードでも実行されます。DaemonSetが削除されると、それによって作成されたポッドはクリアされます。一般に、クラスターログの収集、監視、およびその他のグローバルアプリケーションを展開するために使用されます。
一般的なシナリオは次のとおりです
。1。ceph、glusterdなどのストレージクラスターデーモンを
実行します。2。logstash、fluentdなどのログ収集デーモンを実行します。3。Prometheusなど
の監視デーモンを実行します。Node Exporter、collectd、New Relicエージェント、Gangliagmondなど。
2、スケジューリング戦略
通常の状況では、DaemonSetによって作成されたポッドは、Kubernetesスケジューリングポリシーによって決定されたノードにスケジュールする必要がありますが、実際に事前に決定されたポッドが作成されると、スケジューリングは無視されます。デバイス。したがって：
-
DaemonSetコントローラーは、ノードのスケジュール不可能なフィールドを気にしません。
- スケジューラーが開始されていない場合でも、DaemonSetコントローラーはポッドを作成できます。
ただし、次の方法を使用して、指定したノードでポッドを実行できます。
-
nodeSelector：指定されたラベルに一致するノードにのみディスパッチします。
-
nodeAffinity：セット操作のサポートなど、より豊富な機能を備えたノードセレクター。
- podAffinity：条件を満たすポッドが配置されているノードへのスケジューリング。
2.1、nodeSelector
実行する必要のあるノードにラベルを付けることです。たとえば、ssdハードディスクを搭載したノードでのみ実行する場合、次のノードにラベルを付けることができます。
kubectl label nodes node-01 disktype=ssd次に、DaemonSetのフィールドでnodeSelectorをdisktype = ssdとして定義します。
spec:
nodeSelector:
disktype: ssd2.2、nodeAffinity
nodeAffinityは現在、requiredDuringSchedulingIgnoredDuringExecutionとpreferredDuringSchedulingIgnoredDuringExecutionの2つのタイプをサポートしています。これらは、それぞれ満たす必要のある条件と優先条件を表します。たとえば、次の例は、ラベルkubernetes.io/e2e-az-nameを含み、値がe2e-az1またはe2e-az2であり、ラベルがanother-node-label-key =であるノードへのスケジューリングを表しています。 another-node-label-valueのノード。
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: gcr.io/google_containers/pause:2.02.3、podAffinity
podAffinityは、ポッドのラベルに基づいてノードを選択し、ポッドが条件を満たすノードにのみノードをスケジュールし、podAffinityとpodAntiAffinityをサポートします。この関数はより複雑です。例として次の例を取り上げます。
-
「ノードが配置されているゾーンに、security = S1ラベルがあり、実行中のポッドを持つポッドが少なくとも1つ含まれている」場合は、ノードにスケジュールできます。
- 「security = S2タグを持つ実行中のポッドを少なくとも1つ含む」予定はありません
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: gcr.io/google_containers/pause:2.03、更新
DaemonSetはローリング更新をサポートし、その定義済みフィールドはupdateStrategyであり、kubectl Explainds.spec.updateStrategyで表示できます。
[root@master ~]# kubectl explain ds.spec.updateStrategy
KIND: DaemonSet
VERSION: extensions/v1beta1
RESOURCE: updateStrategy <Object>
DESCRIPTION:
An update strategy to replace existing DaemonSet pods with new pods.
FIELDS:
rollingUpdate <Object>
Rolling update config params. Present only if type = "RollingUpdate".
type <string>
Type of daemon set update. Can be "RollingUpdate" or "OnDelete". Default is
OnDelete.DaemonSetではノードでの実行が1つしか許可されていないため、rollingUpdateフィールドにはmaxUnavailableが1つだけあり、maxSurgeはありません。
DaemonSetには2つの更新戦略があります。
- RollingUpdate：ローリングアップデート
- OnDelete：ポッドを削除するときに更新します。これはデフォルトの更新戦略です。
4、例
ログを収集し、filebeatを使用してログを収集し、filebeatを介してログを収集してredisに送信するDaemonSetを定義します。
# vim filebeat-ds.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: redis
role: cachedb
template:
metadata:
labels:
app: redis
role: cachedb
spec:
containers:
- name: redis
image: redis:5.0.5-alpine
ports:
- name: redis
containerPort: 6379
---
apiVersion: v1
kind: Service
metadata:
name: redis
namespace: default
spec:
type: ClusterIP
selector:
app: redis
role: cachedb
ports:
- port: 6379
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: filebeat-ds
namespace: default
spec:
selector:
matchLabels:
app: filebeat
role: logstorage
template:
metadata:
labels:
app: filebeat
role: logstorage
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.5-alpine
env:
- name: REDIS_HOST
value: redis.default.svc.cluster.local このYAMLファイルを作成します
# kubectl apply -f filebeat-ds.yaml次に、svc、podのステータスを確認します
[root@master daemonset]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.68.0.1 <none> 443/TCP 4d6h
redis ClusterIP 10.68.213.73 <none> 6379/TCP 5s
[root@master daemonset]# kubectl get pods
NAME READY STATUS RESTARTS AGE
filebeat-ds-pgmzt 1/1 Running 0 2m50s
filebeat-ds-wx44z 1/1 Running 0 2m50s
filebeat-ds-zjv68 1/1 Running 0 2m50s
redis-85c7ccb675-ks4rc 1/1 Running 0 4m2s次に、filebeatコンテナに入り、テストデータを取得します。
# kubectl exec -it filebeat-ds-pgmzt -- /bin/bash
# cd /var/log/containers/
# echo "123" > a.log次に、redisコンテナーに入り、データを表示します。
# kubectl exec -it redis-85c7ccb675-ks4rc -- /bin/sh
/data # redis-cli -h redis.default.svc.cluster.local -p 6379
redis.default.svc.cluster.local:6379> KEYS *
1) "filebeat"
redis.default.svc.cluster.local:6379> 以上のことから、Redisはfilebeatで送信された情報を正常に受信していることがわかります。
終了