5.アプリケーションのオーケストレーションと管理：ジョブとデーモンセット
1、仕事
1）、需要の源
2）、ユースケースの解釈
1）ジョブの構文
上の写真はJobの最も単純なyaml形式です。ここでは、Jobと呼ばれる新しい種類が主に紹介されています。このJobは実際にはジョブコントローラーの一種です。次に、メタデータの名前でジョブの名前を指定します。以下のspec.templateは、実際にはポッドの仕様です。
ここの内容は同じですが、唯一のことはさらに2つのポイントです。
- 1つ目はrestartPolicyです。3つの再試行ポリシー：Never、OnFailure、AlwaysをJobで設定できます。ジョブを再実行する場合はNeverを使用でき、失敗したときにジョブを再実行する場合はOnFailureを使用でき、再試行する場合はOnFailureを使用できます。または、任意の場所で再実行する場合はAlwaysを使用できます。状況。
- さらに、ジョブの実行中にジョブを無限に再試行することは不可能であるため、再試行の回数を制御するためのパラメーターが必要です。このbackoffLimitは、ジョブを再試行できる回数を保証するためのものです。
したがって、ジョブでは、主な焦点は、restartPolicyの再起動戦略とbackoffLimitの再試行制限です。
2）仕事の状況
ジョブの作成後、kubectl get jobsこのコマンドを使用して、現在のジョブの実行ステータスを表示できます。得られた値には、基本的にジョブの名前、現在完了しているポッドの数、および所要時間が含まれています。
- AGEの意味は、このポッドが現在の時刻からその時点で作成された時刻を差し引いて計算されることを意味します。この期間は主に、ポッドの履歴と、ポッドが作成されてからの経過時間を示すために使用されます。
- DURATIONは主に、ジョブの実際のビジネスが実行されている時間を調べます。このパラメーターは、パフォーマンスを調整するときに非常に役立ちます。
- COMPLETIONSは主に、タスク内のポッドの数と、タスクが完了した状態の数を確認し、このフィールドに表示されます。
3）ポッドを表示
ジョブの最終実行ユニットは引き続きポッドです。作成したばかりのジョブは、piというポッドを作成します。このタスクは、piを計算することです。ポッドの名前は次のようになります。${job-name}-${random-suffix}
これには、ownerReferencesと呼ばれる通常のポッドよりも1つ多く、ポッドがどの上位レベルのコントローラーに属しているかを宣言して管理します。ここでのownerReferencesは、前のジョブによって管理されているbatch / v1によって所有されていることがわかります。これは、そのコントローラーが誰であるかについてのステートメントです。次に、ポッドバックを介してそのコントローラーが誰であるかを確認できます。同時に、ジョブに応じて、ジョブの下にあるポッドを確認できます。
4）ジョブを並行して実行する
場合によっては、いくつかの要件があります。実行時にジョブを並列に最大化でき、n個のポッドが並列に生成されてすばやく実行できることを願っています。同時に、ノードの数が限られているため、同時に並列になりすぎないポッドが必要になる場合があります。パイプラインの概念があります。並列処理の最大度は、であることが期待できます。ジョブコントローラーは私たちのためにそれを行うことができます。
主に2つのパラメータがあります。1つは補完、もう1つは並列処理です。
- まず、最初のパラメーターは、このポッドキューの実行数を指定するために使用されます。これは、このジョブによって指定された実行の総数と見なすことができます。たとえば、ここでは8に設定されています。つまり、このタスクは合計8回実行されます。
- 2番目のパラメーターは、並列実行の数を表します。いわゆる並列実行数は、実際にはパイプラインまたはバッファー内のバッファーキューのサイズです。2に設定すると、このジョブは8回実行され、毎回2つのポッドが並列に実行される必要があります。この場合、合計4つが実行されます。バッチ
5）実行中の並列ジョブを表示する
上の写真は、ジョブ全体を実行した後に見られる効果です。まず、ジョブの名前を確認し、次に、実行に2分23秒かかった合計8つのポッドが作成されたことを確認します。 。これは作成時間です。
次に、実際のポッドを見てみましょう。合計8つのポッドがあり、各ポッドのステータスが完了しています。次に、そのAGE（時間）を確認します。下から見ると、それぞれ73秒、40秒、110秒、2分26秒あることがわかります。各グループには、同じ時刻の2つのポッドがあります。つまり、期間が40秒の場合、最後のポッドが作成され、2分26秒が最初のポッドが作成されます。つまり、常に2つのポッドが同時に作成され、並列化されて消えてから、作成され、実行されて、再び終了します。
6）CronJob構文
Jobと比較すると、CronJob（時限タスク）にはいくつかの異なるフィールドがあります。
-
スケジュール：このスケジュールフィールドは主に時刻形式を設定するためのものであり、その時刻形式はLinuxのcrontimeと同じです。
-
** startingDeadlineSeconds：**ジョブが実行されるたびに、ジョブが待機できる時間。ジョブが開始されずに長時間実行される場合があります。したがって、この時点で、長時間の場合、CronJobはジョブを停止します
-
concurrencyPolicy：並列操作を許可するかどうかを意味します。たとえば、いわゆる並列操作は毎分実行しますが、このジョブの実行には時間がかかる場合があります。正常に実行するのに2分かかる場合、つまり2番目のジョブを時間内に実行する必要がある場合は、前のジョブはまだ完了していません。このポリシーがtrueに設定されている場合、前のジョブが完了したかどうかに関係なく、毎分実行されます。falseの場合、前のジョブが完了するのを待ってから次のジョブを実行します。
-
** JobsHistoryLimit：**これは、各CronJobが実行された後、前のジョブの実行履歴と表示時間を残すことを意味します。もちろん、この量を無制限にすることはできないため、履歴保持の数を設定する必要があります。通常、デフォルトの10または100を設定できます。
3）操作デモンストレーション
1）雇用創出と運用検証
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
hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f job.yaml
job.batch/pi created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
pi 1/1 2m1s 2m26s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME READY STATUS RESTARTS AGE
pi-hltwn 0/1 Completed 0 2m34s
hanxiantaodeMBP:yamls hanxiantao$ kubectl logs pi-hltwn
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
2）並列ジョブの作成と動作の検証
job1.yaml：
apiVersion: batch/v1
kind: Job
metadata:
name: paral-1
spec:
completions: 8
parallelism: 2
template:
spec:
containers:
- name: param
image: ubuntu
command: ["/bin/bash"]
args: ["-c","sleep 30;date"]
restartPolicy: OnFailure
hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f job1.yaml
job.batch/paral-1 created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
paral-1 0/8 10s 10s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME READY STATUS RESTARTS AGE
paral-1-9gs52 1/1 Running 0 22s
paral-1-vjc5v 1/1 Running 0 22s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME READY STATUS RESTARTS AGE
paral-1-7t6qf 0/1 Completed 0 102s
paral-1-9gs52 0/1 Completed 0 2m31s
paral-1-fps7x 0/1 Completed 0 107s
paral-1-hflsd 0/1 Completed 0 39s
paral-1-qfnk9 0/1 Completed 0 37s
paral-1-t5dqw 0/1 Completed 0 70s
paral-1-vjc5v 0/1 Completed 0 2m31s
paral-1-vqh7d 0/1 Completed 0 73s
3）cronジョブの作成と動作の検証
cron.yaml：
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date;echo Hello from ther Kubernetes Cluster
restartPolicy: OnFailure
startingDeadlineSeconds: 10
concurrencyPolicy: Allow
successfulJobsHistoryLimit: 3
hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f cron.yaml
cronjob.batch/hello created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
No resources found in default namespace.
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
hello-1609464960 1/1 4s 5s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
hello-1609464960 1/1 4s 66s
hello-1609465020 1/1 3s 6s
このCronJobは毎分実行されるためkubectl get jobs、最初はジョブ情報が表示されない場合がありますので、しばらくお待ちください。
4）、アーキテクチャ設計
実際、ジョブコントローラーは依然として主に対応するポッドを作成するためのものであり、ジョブコントローラーはジョブのステータスを追跡し、再試行するか、タイムリーに送信された構成の一部に従って作成を続行します。各ポッドには対応するラベルがあり、ポッドが属するジョブコントローラーを追跡し、ポッドを作成するための並列作成、並列またはシリアルの構成も行います。
上の図は、ジョブコントローラーのメインフローです。すべてのジョブはコントローラーです。APIサーバーを監視します。ジョブが送信されるたびに、yamlはapi-serverを介してetcdに渡され、ジョブコントローラーは、追加、更新、または削除。操作を待機しているときは、メモリレベルのメッセージキューを介してコントローラーに送信されます。
Job Controllerを介して現在実行中のポッドがあるかどうかを確認します。存在しない場合は、スケールアップを使用してポッドを作成します。存在する場合、またはこの数より大きい場合は、スケールダウンします。この時点でポッドが変更された場合は、時間内にステータスを更新する
同時に、並列ジョブかシリアルジョブかを確認し、構成された並列処理とシリアル化の程度に応じて、適時にポッドの数を作成します。最後に、ジョブのステータス全体をAPIサーバーに更新して、提示された最終的な効果を確認できるようにします。
2、デーモンセット
1）、需要の源
2）、ユースケースの解釈
1）DaemonSet構文
1つ目は種類です：DaemonSet。DaemonSetの構文は、Deploymentと同じ部分です。たとえば、対応するポッドを管理するためにmatchLabelを介してmatchLabelがあり、このpod.labelもこのDaemonSet.controller.labelと一致する必要があり、label.selectorに従って見つけることができます。対応する管理ポッド。以下のspec.containerのすべてが一貫しています
ここでは、例としてfluentdを使用します。DaemonSetで最も一般的に使用されるポイントは次のとおりです。
-
1つ目はストレージです。GlusterFSやCephのようなものは、各ノードでエージェントと同様の何かを実行する必要があります。DaemonSetはこの需要を十分に満たすことができます。
-
さらに、logstashやfluentdなどのログ収集の場合、これらは同じ要件です。各ノードはエージェントを実行する必要があります。これにより、そのステータスを簡単に収集し、各ノードの情報を時間内に報告できます。上
-
もう1つは、各ノードがいくつかの監視機能を実行する必要があり、各ノードが同じことを実行する必要があることです。たとえば、Promethuesは、DaemonSetのサポートも必要です。
2）DaemonSetのステータスを表示します
DaemonSetを作成した後、それを使用できますkubectl get DaemonSet（DaemonSetはdsと省略されます）。DaemonSetの戻り値はデプロイメントと非常に似ていることがわかります。つまり、現在いくつか実行されており、いくつか必要であり、いくつかは準備ができています。もちろん、READYにはポッドしかないため、最終的に作成されるのはポッドだけです。
ここにはいくつかのパラメーターがあります。つまり、必要なポッドの数、作成されたポッドの数、準備ができているポッドの数、およびヘルスチェックに合格した使用可能なすべてのポッド、およびNODESELECTORです。NODE SELECTORはノード選択ラベルです。すべてのノードではなく、一部のノードのみでこのポッドを実行したい場合があるため、一部のノードがマークされている場合、DaemonSetはこれらのノードでのみ実行されます。
3）DaemonSetを更新します
実際、DaemonSetとデプロイメントは非常に似ており、2つの更新戦略もあります。1つはRollingUpdateで、もう1つはOnDeleteです。
-
RollingUpdateは1つずつ更新します。最初に最初のポッドを更新し、次に古いポッドを削除し、ヘルスチェックに合格した後に2番目のポッドを構築して、ビジネスが中断することなくスムーズにアップグレードできるようにします。
-
OnDeleteは実際には非常に優れた更新戦略です。つまり、テンプレートが更新された後はポッドに変更がないため、手動で制御する必要があります。特定のノードに対応するポッドを削除すると再構築されます削除しないと再構築されませんこのように、手動で制御する必要のある特別なニーズにも特に効果があります。
3）操作デモンストレーション
1）デーモンセットの配置
demoSet.yaml：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
containers:
- name: fluentd-elasticsearch
image: fluent/fluentd:v1.4-1
hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f daemonSet.yaml
daemonset.apps/fluentd-elasticsearch created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get ds
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
fluentd-elasticsearch 1 1 1 1 1 <none> 35s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fluentd-elasticsearch-h9jb9 1/1 Running 0 2m17s
2）DaemonSetの更新
hanxiantaodeMBP:yamls hanxiantao$ kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=fluent/fluentd:v1.4
daemonset.apps/fluentd-elasticsearch image updated
hanxiantaodeMBP:yamls hanxiantao$ kubectl rollout status ds/fluentd-elasticsearch
daemon set "fluentd-elasticsearch" successfully rolled out
4）、アーキテクチャ設計
DaemonSetもコントローラーであり、その最終的な実際のビジネスユニットもポッドです。DaemonSetは実際にはジョブコントローラーと非常によく似ています。また、コントローラーを使用してAPIサーバーのステータスを監視し、ポッドを時間内に追加します。唯一の違いは、ノードのステータスを監視することです。ノードが新しく追加または削除されると、ノード上に対応するポッドが作成され、構成したラベルに従って対応するノードが選択されます。
DaemonSetのコントローラーであるDaemonSetは、実際にはJobコントローラーと同じことを行います。どちらもAPIサーバーウォッチの状態に基づいている必要があります。DaemonSetとJobコントローラーの唯一の違いは、DaemonsetSetコントローラーがノードの状態を監視する必要があることですが、実際には、このノードの状態はAPIサーバーを介してetcdに渡されます。
ノードの状態が変化すると、メモリメッセージキューを介して送信され、DaemonSetコントローラーはこの状態を監視して、各ノードに対応するポッドがあるかどうかを確認し、ない場合は作成します。もちろん、比較を行います。存在する場合は、バージョンを比較してから、上記のRollingUpdateを実行するかどうかを追加しますか？そうでない場合は再作成されます。Ondeleteがポッドを削除すると、対応するポッドを更新するか作成するかを確認するためにポッドもチェックされます。
もちろん、最後に、すべての更新が完了すると、DaemonSet全体のステータスがAPIサーバーに更新され、最終的な更新が完了します。
6、アプリケーション構成管理
1.需要の源
2、ConfigMap
3、秘密
4、ServiceAccount
5、リソース
6、SecurityContext
7、InitContainer
コースアドレス：https：//edu.aliyun.com/roadmap/cloudnative？spm = 5176.11399608.aliyun-edu-index-014.4.dc2c4679O3eIId＃suit