目次
1. ポッドコントローラー
1.1 ポッドコントローラーとその機能
- ポッド コントローラー (ワークロードとも呼ばれる) は、ポッド リソースが期待されるステータスを確実に満たすようにポッドを管理するために使用される中間層です。ポッド リソースに障害が発生すると、再起動が試行されます。再起動ポリシーが無効な場合、ポッド リソースは再起動されます。 -作成した。
1.2 ポッド コントローラーにはさまざまな種類があります
- 1. ReplicaSet: ユーザーに代わって指定された数のポッド コピーを作成し、ポッド コピーの数が期待されるステータスを満たしていることを確認し、ローリング自動拡張機能と縮小機能をサポートします。
ReplicaSet は主に 3 つのコンポーネントで構成されます。
(1) ユーザーが予期するポッド コピーの数
(2) ユーザーがどのポッドを管理するかを決定するラベル セレクター
(3) 既存のポッドの数が不十分な場合、ポッド リソース テンプレートに基づいて新しいポッドが作成され
、ユーザーがステートレス ポッド リソースを管理し、正確に応答できるようにします。ユーザー定義の目標数量ですが、RelicaSet は直接使用されるコントローラーではなく、Deployment が使用されます。
-
2. デプロイメント: ReplicaSet 上で動作し、ステートレス アプリケーションの管理に使用され、現時点では最良のコントローラーです。ローリング更新およびロールバック機能をサポートし、宣言型構成も提供します。
2 つのリソース オブジェクト ReplicaSet と Deployment は、RC の以前の役割を段階的に置き換えます。 -
3. DaemonSet: クラスター内の各ノードが特定のポッド コピーのみを実行することを保証するために使用され、通常はシステム レベルのバックグラウンド タスクを実装するために使用されます。たとえば、ELK サービスの
機能は次のとおりです。 サービスはステートレスであり、
サービスはデーモン プロセスである必要があります。 -
4. StatefulSet: ステートフル アプリケーションを管理する
-
5. ジョブ: 完了したらすぐに終了します。再起動や再構築の必要はありません。
-
6. Cronjob: 定期的なタスク制御。バックグラウンドで実行し続ける必要はありません。
1.3Podとコントローラーの関係
- コントローラー: クラスター上のコンテナーを管理および実行するポッド オブジェクト。ポッドはラベル セレクターを通じて関連付けられます。
- ポッドは、コントローラーを介してスケーリングやアップグレードなどのアプリケーションの運用とメンテナンスを実装します。
2.展開
ステートレス アプリケーションのデプロイオンライン デプロイメント、レプリカ設定、ローリング アップグレード、ロールバックなどの機能による
Pod と ReplicaSet の管理新しいイメージのみの更新などの宣言的な更新の提供アプリケーション シナリオ: Web サービス
例
vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
kubectl create -f nginx-deployment.yaml
kubectl get pods,deploy,rs
コントローラー構成の表示
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-04-19T08:13:50Z"
generation: 1
labels:
app: nginx #Deployment资源的标签
name: nginx-deployment
namespace: default
resourceVersion: "167208"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
progressDeadlineSeconds: 600
replicas: 3 #期望的pod数量，默认是1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25% #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
maxUnavailable: 25% #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
type: RollingUpdate #滚动升级
template:
metadata:
creationTimestamp: null
labels:
app: nginx #Pod副本关联的标签
spec:
containers:
- image: nginx:1.15.4 #镜像名称
imagePullPolicy: IfNotPresent #镜像拉取策略
name: nginx
ports:
- containerPort: 80 #容器暴露的监听端口
protocol: TCP
resources: {
}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always #容器重启策略
schedulerName: default-scheduler
securityContext: {
}
terminationGracePeriodSeconds: 30
過去のバージョンを表示する
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>
3. ステートフルセット
安定した永続ストレージを使用してステートフル アプリケーションをデプロイします
。つまり、ポッドが再スケジュールされた後も同じ永続データにアクセスできます。安定したネットワーク フラグを実現するために PVC に基づいています。つまり、ポッドが再スケジュールされた後も、その PodName と HostName は変更されません
。ヘッドレス サービス (つまり、クラスター IP のないサービス) で、
秩序あるデプロイメントと秩序ある拡張を実現します。つまり、ポッドが順番に配置されており、定義された順序 (つまり、0 から N まで) に従って順番にデプロイまたは拡張する必要があります。 -1、次のポッドで実行します。以前のすべてのポッドは実行中および準備完了ステータスである必要があります)。初期化コンテナに基づいて、
秩序ある縮小と秩序ある削除 (つまり、N-1 から 0 へ) を実現します。
一般的なアプリケーション シナリオ: データベース
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
3.1 上記のアプリケーション シナリオから、StatefulSet は次の部分で構成されていることがわかります。
●ヘッドレスサービス: ポッドリソース識別子の解決可能な DNS レコードを生成するために使用されます。
●volumeClaimTemplates (ストレージボリュームアプリケーションテンプレート): 静的または動的 PV 供給方法に基づいて、Pod リソースに専用の固定ストレージを提供します。
●StatefulSet: Podリソースの管理と制御に使用されます。
3.2 なぜヘッドレスにする必要があるのですか?
- デプロイメントでは、各ポッドには名前がなく、ランダムな文字列であり、順序付けされていません。Statefulset には順序付けが必要であり、各ポッドの名前は固定されている必要があります。ノードに障害が発生した場合、再構築後の識別子は変更されず、各ノードのノード名は変更できません。ポッド名はポッドを識別するために使用される一意の識別子であり、その識別子は安定していて一意である必要があります。
- 識別子の安定性を実現するには、ヘッドレス サービスが識別子をポッドに直接解決する必要があり、ポッドに一意の名前を構成する必要があります。
3.3 volumeClaimTemplate が必要なのはなぜですか?
ほとんどのステートフル レプリカ セットは永続ストレージを使用します。たとえば、分散システムではデータが異なるため、各ノードには独自の専用ストレージ ノードが必要です。デプロイメントのポッド テンプレートで作成されたストレージ ボリュームは共有ストレージ ボリュームです。複数のポッドが同じストレージ ボリュームを使用します。ただし、ステートフルセット定義内の各ポッドは同じストレージ ボリュームを使用できません。したがって、ポッドはポッド テンプレートに基づいて作成されますstatefulset を使用してポッドを作成すると、PVC が自動的に生成され、PV を独自の専用ストレージ ボリュームにバインドするよう要求されます。
3.4 サービスの検出
サービス ディスカバリ: アプリケーション サービス間の相互位置付けのプロセスです。
アプリケーションシナリオ:
●非常に動的: ポッドは他のノードにフロートします
●頻繁なアップデートとリリース: インターネットの考え方は小さなステップで実行され、最初に実装してから最適化します。上司は常に最初にオンラインになり、その後ゆっくりと最適化して、最初にアイデアを形にします。お金を稼ぐための製品 お金を手に入れたら、少しずつ最適化できます。
●自動スケーリングをサポート: 大きなセールが発生したら、必ず複数のコピーを拡張する必要があります。
K8S のサービス検出方法 - DNS により、K8S クラスターがサービス リソースの「名前」と「CLUSTER-IP」を自動的に関連付けることができるため、クラスターによってサービスが自動的に検出されます。
K8S で DNS 機能を実装するプラグイン:
●skyDNS: Kubernetes 1.3 より前のバージョン
●kubeDNS: Kubernetes 1.3 ～ Kubernetes 1.11
●CoreDNS: Kubernetes 1.11 以降
3.5 CoreDNSのインストール
方法 1
下载链接:
https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base
vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g
sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml
方法 2: coredns.yaml ファイルをアップロードする
kubectl create -f coredns.yaml
kubectl get pods -n kube-system
vim nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx
kubectl create -f nginx-service.yaml
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d19h
nginx-service NodePort 10.96.173.115 <none> 80:31756/TCP 10s
vim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.28.4
args:
- /bin/sh
- -c
- sleep 36000
restartPolicy: Never
kubectl create -f pod6.yaml
kubernetes および nginx サービス名を解析する
kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
/ # nslookup nginx-service
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: nginx-service
Address 1: 10.96.173.115 nginx-service.default.svc.cluster.local
//查看statefulset的定义
kubectl explain statefulset
KIND: StatefulSet
VERSION: apps/v1
DESCRIPTION:
StatefulSet represents a set of pods with consistent identities. Identities
are defined as: - Network: A single stable DNS and hostname. - Storage: As
many VolumeClaims as requested. The StatefulSet guarantees that a given
network identity will always map to the same storage identity.
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>
kubectl explain statefulset.spec
KIND: StatefulSet
VERSION: apps/v1
RESOURCE: spec <Object>
DESCRIPTION:
Spec defines the desired identities of pods in this set.
A StatefulSetSpec is the specification of a StatefulSet.
FIELDS:
podManagementPolicy <string> #Pod管理策略
replicas <integer> #副本数量
revisionHistoryLimit <integer> #历史版本限制
selector <Object> -required- #选择器，必选项
serviceName <string> -required- #服务名称，必选项
template <Object> -required- #模板，必选项
updateStrategy <Object> #更新策略
volumeClaimTemplates <[]Object> #存储卷申请模板，必选项
マニフェスト定義StatefulSet
前述したように、完全な StatefulSet コントローラーは、Headless Service、StatefulSet、および volumeClaimTemplate で構成されます。以下のリソース リストで定義されているように:
vim stateful-demo.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
labels:
app: myapp-svc
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: myapp
spec:
serviceName: myapp-svc
replicas: 3
selector:
matchLabels:
app: myapp-pod
template:
metadata:
labels:
app: myapp-pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: myappdata
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: myappdata
annotations: #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联
volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 2Gi
PVの作成
/stor01节点
mkdir -p /data/volumes/v{
1,2,3,4,5}
vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)
systemctl restart rpcbind
systemctl restart nfs
exportfs -arv
showmount -e
//定义PV
vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /data/volumes/v1
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /data/volumes/v2
server: stor01
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /data/volumes/v3
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /data/volumes/v4
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv005
labels:
name: pv005
spec:
nfs:
path: /data/volumes/v5
server: stor01
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
kubectl apply -f pv-demo.yaml
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 7s
pv002 2Gi RWO Retain Available 7s
pv003 2Gi RWO,RWX Retain Available 7s
pv004 2Gi RWO,RWX Retain Available 7s
pv005 2Gi RWO,RWX Retain Available 7s
//创建statefulset
kubectl apply -f stateful-demo.yaml
kubectl get svc #查看创建的无头服务myapp-svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 50d
myapp-svc ClusterIP None <none> 80/TCP 38s
kubectl get sts #查看statefulset
NAME DESIRED CURRENT AGE
myapp 3 3 55s
kubectl get pvc #查看pvc绑定
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myappdata-myapp-0 Bound pv002 2Gi RWO 1m
myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 1m
myappdata-myapp-2 Bound pv004 2Gi RWO,RWX 1m
kubectl get pv #查看pv绑定
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 1Gi RWO,RWX Retain Available 6m
pv002 2Gi RWO Retain Bound default/myappdata-myapp-0 6m
pv003 2Gi RWO,RWX Retain Bound default/myappdata-myapp-1 6m
pv004 2Gi RWO,RWX Retain Bound default/myappdata-myapp-2 6m
pv005 2Gi RWO,RWX Retain Available 6m
kubectl get pods #查看Pod信息
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 2m
myapp-1 1/1 Running 0 2m
myapp-2 1/1 Running 0 2m
//当删除一个 StatefulSet 时，该 StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序且体面地终止，可以在删除之前将 StatefulSet 缩容到 0。
kubectl scale statefulset myappdata-myapp --replicas=0
kubectl delete -f stateful-demo.yaml
//此时PVC依旧存在的，再重新创建pod时，依旧会重新去绑定原来的pvc
kubectl apply -f stateful-demo.yaml
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
myappdata-myapp-0 Bound pv002 2Gi RWO 5m
myappdata-myapp-1 Bound pv003 2Gi RWO,RWX 5m
myappdata-myapp-2 Bound pv004 2Gi RWO,RWX
ローリングアップデート
//StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。
vim stateful-demo.yaml #修改image版本为v2
.....
image: ikubernetes/myapp:v2
....
kubectl apply -f stateful-demo.yaml
kubectl get pods -w #查看滚动更新的过程
NAME READY STATUS RESTARTS AGE
myapp-0 1/1 Running 0 29s
myapp-1 1/1 Running 0 27s
myapp-2 0/1 Terminating 0 26s
myapp-2 0/1 Terminating 0 30s
myapp-2 0/1 Terminating 0 30s
myapp-2 0/1 Pending 0 0s
myapp-2 0/1 Pending 0 0s
myapp-2 0/1 ContainerCreating 0 0s
myapp-2 1/1 Running 0 31s
myapp-1 1/1 Terminating 0 62s
myapp-1 0/1 Terminating 0 63s
myapp-1 0/1 Terminating 0 66s
myapp-1 0/1 Terminating 0 67s
myapp-1 0/1 Pending 0 0s
myapp-1 0/1 Pending 0 0s
myapp-1 0/1 ContainerCreating 0 0s
myapp-1 1/1 Running 0 30s
myapp-0 1/1 Terminating 0 99s
myapp-0 0/1 Terminating 0 100s
myapp-0 0/1 Terminating 0 101s
myapp-0 0/1 Terminating 0 101s
myapp-0 0/1 Pending 0 0s
myapp-0 0/1 Pending 0 0s
myapp-0 0/1 ContainerCreating 0 0s
myapp-0 1/1 Running 0 1s
//在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的
kubectl exec -it myapp-0 /bin/sh
Name: myapp-0.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.27 myapp-0.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-1.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-1.myapp-svc.default.svc.cluster.local
Address 1: 10.244.1.14 myapp-1.myapp-svc.default.svc.cluster.local
/ # nslookup myapp-2.myapp-svc.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: myapp-2.myapp-svc.default.svc.cluster.local
Address 1: 10.244.2.26 myapp-2.myapp-svc.default.svc.cluster.local
//从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local
3.6 概要
ステタスはありません：
1) デプロイではすべてのポッドが同じであると見なされます
2) 順序要件を考慮する必要はありません
3) ノードがどのノードで実行されているかを考慮する必要はありません
4) 容量は自由に拡張および削減できます
ステートフル
1) インスタンス間に違いがあります。各インスタンスには独自の一意性と、etcd、zookeeper などの異なるメタデータがあります。2
) インスタンス間の非対称関係と、外部ストレージに依存するアプリケーション。
通常サービスとヘッドレスサービスの違い
サービス: クラスター-IP クラスター間の通信、負荷分散およびサービス検出を提供する一連のポッド アクセス ポリシー。
ヘッドレス サービス: クラスター IP を必要としないヘッドレス サービスの代わりに、DNS レコードを通じてプロキシされたポッドの IP アドレスを直接解決します。
vim pod6.yaml
apiVersion: v1
kind: Pod
metadata:
name: dns-test
spec:
containers:
- name: busybox
image: busybox:1.28.4
args:
- /bin/sh
- -c
- sleep 36000
restartPolicy: Never
vim sts.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: nginx-statefulset
namespace: default
spec:
serviceName: nginx
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
kubectl apply -f sts.yaml
kubectl apply -f pod6.yaml
kubectl get pods,svc
kubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx.default.svc.cluster.local
kubectl exec -it nginx-statefulset-0 bash
/# curl nginx-statefulset-0.nginx
/# curl nginx-statefulset-1.nginx
/# curl nginx-statefulset-2.nginx
//扩展伸缩
kubectl scale sts myapp --replicas=4 #扩容副本增加到4个
kubectl get pods -w #动态查看扩容
kubectl get pv #查看pv绑定
kubectl patch sts myapp -p '{"spec":{"replicas":2}}' #打补丁方式缩容
kubectl get pods -w #动态查看缩容
4.デーモンセット
- DaemonSet は、すべて (または一部) のノードがポッドのコピーを実行していることを保証します。ノードがクラスターに参加すると、ポッドがクラスターに追加されます。ノードがクラスターから削除されると、これらのポッドもリサイクルされます。DaemonSet を削除すると、DaemonSet が作成したすべての Pod が削除されます。
DaemonSet の一般的な使用例は次のとおりです。
●各ノードで glusterd や ceph などのクラスター ストレージ デーモンを実行します。
●fluentd や logstash などのログ収集デーモンを各ノードで実行します。
●Prometheus Node Exporter、collectd、Datadog エージェント、New Relic エージェント、Ganglia gmond などの監視デーモンを各ノードで実行します。
アプリケーションシナリオ: エージェント
//公式ケース (モニタリング)
https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
例：
vim ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-daemonSet
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
kubectl apply -f ds.yaml
//DaemonSet会在每个node节点都创建一个Pod
kubectl get pods
nginx-deployment-4kr6h 1/1 Running 0 35s
nginx-deployment-8jrg5 1/1 Running 0 35s
5. 仕事
ジョブは通常のタスク (Job) とスケジュールされたタスク (CronJob) に分けられ、
これらは 1 回だけ実行する必要があるタスクの実行によく使用されます
アプリケーション シナリオ: データベース移行、バッチ スクリプト、kube-bench スキャン、オフライン データ処理、ビデオデコードおよびその他のサービス
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
例：
vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
//参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。
.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。
//在所有node节点下载perl镜像，因为镜像比较大，所以建议提前下载好
docker pull perl
kubectl apply -f job.yaml
kubectl get pods
pi-bqtf7 0/1 Completed 0 41s
//结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......
//清除job资源
kubectl delete -f job.yaml
//backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
restartPolicy: Never
backoffLimit: 2
kubectl apply -f job-limit.yaml
kubectl get job,pods
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/1 4m34s 4m34s
NAME READY STATUS RESTARTS AGE
pod/busybox-dhrkt 0/1 Error 0 4m34s
pod/busybox-kcx46 0/1 Error 0 4m
pod/busybox-tlk48 0/1 Error 0 4m21s
kubectl describe job busybox
......
Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit
6. クロンジョブ
Linux の Crontab のような定期的なタスク。
定期タスクの
アプリケーション シナリオ: 通知、バックアップ
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
例：
//每分钟打印hello
vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
//cronjob其它可用参数的配置
spec:
concurrencyPolicy: Allow #声明了 CronJob 创建的任务执行时发生重叠如何处理（并发性规则仅适用于相同 CronJob 创建的任务）。spec仅能声明下列规则中的一种:
●Allow (默认)：CronJob 允许并发任务执行。
●Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
●Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。
startingDeadlineSeconds: 15 #它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务，且标记失败.如果此字段未设置，那任务就没有最后期限。
successfulJobsHistoryLimit: 3 #要保留的成功完成的任务数（默认为3）
failedJobsHistoryLimit：1 #要保留多少已完成和失败的任务数（默认为1）
suspend：true #如果设置为 true ，后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。
schedule: '*/1 * * * *' #必需字段，作业时间表。在此示例中，作业将每分钟运行一次
jobTemplate: #必需字段，作业模板。这类似于工作示例
kubectl create -f cronjob.yaml
kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 25s
kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1621587180-mffj6 0/1 Completed 0 3m
hello-1621587240-g68w4 0/1 Completed 0 2m
hello-1621587300-vmkqg 0/1 Completed 0 60s
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错：Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解决办法：绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous