二つの方法でポッドをスケジュール、1はポッドのコントローラを介して、ポッド別のプロパティ自身のリソースを提供することです
コントローラのポッドの役割
ポッドコントローラ上で直接作成されたポッドの記事は、K8Sの機能の一部を実現することは困難である、経営ではありません。
kubeletは、各作業ノードの1つのインスタンスで実行されているK8Sクラスタノード剤です。作業ノードに障害が発生した場合、使用できなくもkubelet、ポッドは、もはやkubeletを再起動することはできません。このとき、ポッドポッドの生存率は、一般にワーキングノード外部コントローラによって保証します。
K8Sでは、操作の理想的なモードは、コントローラは、ポッドポッドを管理する必要があり、ポッドの保証は、ユーザー定義での作業にリソースを必要な。
ポッドコントローラタイプのコメント
さらにreplicaSet（略称RS）
モデルreplicationControllerを向上させることである、ポッドは、通常の数（Duotuishaobu）ポッドとサポートポッドスケーラブルな容量を確保するために、（障害発生後に再起動または再構築）正常な動作を保証することができます。
サポートさらにreplicaSetセレクタの組み立て（ReplicationControllerだけで式をサポートしています）
三つの主要なビルディング・ブロックがあります。
- レプリカ：指定したユーザが希望部数
- セレクタ：管理制御ポッドを決定するタグセレクタ
- テンプレート：新しいポッドを作成するためのポッドリソーステンプレートは、テンプレートは、方法は、リソース定義ポッドを参照してください定義します
作成さらにreplicaSet
次のようにNGX-relicatSet-YAML読み取り
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: ngx-rs
tier: frontend
spec:
replicas: 3 ##指定总共需要3个pod
selector: ##通过label选择接受管理的pod
matchLabels:
tier: frontend
template: ##依据此模板生成Pod
metadata:
labels:
tier: frontend
spec:
containers:
- name: ngxv2
image: 192.168.80.146:5000/my_ngx:v2
経営ポッドをさらにreplicaSet対応するポッドマネージャを生成するkubernetesクラスタにこのファイルを送信
[root@k8s-master k8s-yaml]# kubectl create -f ngx-relicatSet-yaml
ポッドマネージャのステータスを表示
[root@k8s-master k8s-yaml]# kubectl get rs frontend
NAME DESIRED CURRENT READY AGE
frontend 3 3 3 10m
[root@k8s-master k8s-yaml]# kubectl describe rs/frontend
Name: frontend
Namespace: default
Selector: tier=frontend
Labels: app=ngx-rs
tier=frontend
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: tier=frontend
Containers:
ngxv2:
Image: 192.168.80.146:5000/my_ngx:v2
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 13m replicaset-controller Created pod: frontend-6z7wn
Normal SuccessfulCreate 13m replicaset-controller Created pod: frontend-dp9xv
Normal SuccessfulCreate 11m replicaset-controller Created pod: frontend-v8dkp
ポッドポッド関係マネージャと非テンプレートが作成された検証
以前に作成したコントローラさらにreplicaSet（フロントエンド）を、今POD1（経営者のselectotに沿ってそのラベル）を作成し、POD1の状況を観察します。
次のようにYAMLリストのPOD1は以下のとおりです。
apiVersion: v1
kind: Pod
metadata:
name: pod1
labels:
tier: frontend ##此label符合管理器replicaSet中的selector要求，故会受控制
spec:
containers:
- name: hello1
image: 192.168.80.146:5000/my_ngx:v2
ポッドさらにreplicaSet新規取得が可能、かつ管理されていないでしょう。それは必要な数のポッドを超えてしまいますので、それは新しいPOD1を終了します。
[root@k8s-master k8s-yaml]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
frontend-6z7wn 1/1 Running 0 24m
frontend-dp9xv 1/1 Running 0 24m
frontend-v8dkp 1/1 Running 0 23m
pod1 0/1 Terminating 0 5s
？注：POD1を作成する場合は、さらにreplicaSetを作成し、唯一のそれはPOD1が動作したままになるときに、2つのポッドを生成するためのテンプレートに基づいており、さらにreplicaSetを作成
ポッドでさらにreplicaSetから削除は
編集にラベルポッドであり、マネージャーは自動的に新しい代替ポッドを作成します。
[root@k8s-master k8s-yaml]# kubectl label pods frontend-6z7wn tier=test --overwrite
pod/frontend-6z7wn labeled
[root@k8s-master k8s-yaml]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
frontend-6z7wn 1/1 Running 0 2h tier=test
frontend-c9h5l 0/1 ContainerCreating 0 5s tier=frontend
frontend-dp9xv 1/1 Running 0 2h tier=frontend
frontend-v8dkp 1/1 Running 0 2h tier=frontend
設定部数変更する
だけでさらにreplicaSetを拡大または縮小するためにマニフェストファイル.spec.replicasフィールドを更新します。
[root@k8s-master k8s-yaml]# kubectl apply -f ngx-relicatSet-yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
replicaset.apps/frontend configured
[root@k8s-master k8s-yaml]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
frontend-6z7wn 1/1 Running 0 2h tier=test
frontend-dp9xv 1/1 Running 0 2h tier=frontend
frontend-v8dkp 1/1 Running 0 2h tier=frontend
カスタム更新、またはまったく更新スケジュールを必要としない限り、そうでない場合は、私たちは展開を使用することをお勧めします。むしろ、直接さらにreplicaSetを使用するよりも。
配備
さらにreplicaSetに基づいて、コントローラはRepilicaSetを制御することにより、ポッドを管理し、さらにreplicaSetは宣言ポッドとアップデートを提供します。
展開は、所望の状態で所望の状態に制御意志徐々に展開実際の更新に記載されています。定義することで展開が新しいさらにreplicaSetを作成、または既存の展開を削除し、新しい展開がすべてのリソースを引き継ぐ使用します。
展開を作成します
展開リスト
apiVersion: apps/v1
kind: Deployment
metadata:
name: ngx-deployment ##定义一个名为ngx-deployment的deployment
labels:
app: ngx
spec:
replicas: 3 ##定义有三个Pod
selector:
matchLabels: ##定义找到label为app:ngx的pod
app: ngx
template: ##定义pod的模板
metadata:
labels:
app: ngx ##定义pod的label为app:ngx
spec:
containers:
- name: ngxv2
image: 192.168.80.146:5000/my_ngx:v2
この展開を作成します
[root@k8s-master k8s-yaml]# kubectl apply -f ngx-deployment.yaml
deployment.apps/ngx-deployment created
[root@k8s-master k8s-yaml]# kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
ngx-deployment 3 3 3 3 28s
[root@k8s-master k8s-yaml]# kubectl get rs
NAME DESIRED CURRENT READY AGE
ngx-deployment-559486d8fd 3 3 3 12m
[root@k8s-master k8s-yaml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
ngx-deployment-559486d8fd-4c49k 1/1 Running 0 13m
ngx-deployment-559486d8fd-hfht7 1/1 Running 0 13m
ngx-deployment-559486d8fd-pk967 1/1 Running 0 13m
展開によって作成されたが頭の展開の名前で、その名前をRS。
コンテナポッドを更新
ポッドと場合にのみ配置テンプレート（すなわち.spec.template）の展開ロールオーバートリガーに変更した場合
の例、減少したのV1、V2によってポッドコンテナのバージョンを変更します
[root@k8s-master k8s-yaml]# kubectl edit deployment.v1.apps/ngx-deployment
"/tmp/kubectl-edit-ltme5.yaml" 69L, 2277C written
注：NGX-deployment.yamlを変更しませんが、kubectlに新しい一時ファイル配信アプリケーションを作成します
進捗ロールオーバー観察
[root@k8s-master k8s-yaml]# kubectl rollout status deployment.v1.apps/ngx-deployment
Waiting for deployment "ngx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "ngx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "ngx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "ngx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "ngx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "ngx-deployment" successfully rolled out
アップデート後に観察された変化は、古いRSは保持されますが、唯一の新しいRSと新しいポッドを実行します
[root@k8s-master k8s-yaml]# kubectl get rs
NAME DESIRED CURRENT READY AGE
ngx-deployment-559486d8fd 0 0 0 35m
ngx-deployment-58d847f49c 3 3 3 13m
[root@k8s-master k8s-yaml]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
ngx-deployment 3 3 3 3 35m
[root@k8s-master k8s-yaml]# kubectl get pods
NAME READY STATUS RESTARTS AGE
ngx-deployment-58d847f49c-fjsgr 1/1 Running 0 15m
ngx-deployment-58d847f49c-sjqrq 1/1 Running 0 15m
ngx-deployment-58d847f49c-znw5d 1/1 Running 0 15m
deployment可以确保在更新时只有一定数量的Pod可能会关闭。默认情况下，它确保最多不可用Pod为所需数量的25％；还确保在所需数量的Pod之上只能创建一定数量的Pod。默认情况下，它确保最多比所需数量的Pod多25％
あなたは、展開の上によく見る場合たとえば、あなたはそれが最初に新しいポッド作成を参照して、いくつかの古いポッドを削除し、新しいポッドを作成します。新しいポッドが表示され、十分な数のがある前に、それは昔のポッドを殺さないだろう、と古いポッドの十分な数が殺されるまで、新しいポッドを作成しません。これは、確実に使用可能なポッドの数は少なくとも2、及び4ポッドまでの合計数
ロールオーバーの
歴史の最初のビューの前にロールオーバー、および特定のアップデート
[root@k8s-master k8s-yaml]# kubectl rollout history deployment.v1.apps/ngx-deployment
deployments "ngx-deployment"
REVISION CHANGE-CAUSE
3 <none>
4 <none>
[root@k8s-master k8s-yaml]# kubectl rollout history deployment.v1.apps/ngx-deployment --revision=3
deployments "ngx-deployment" with revision #3
Pod Template:
Labels: app=ngx
pod-template-hash=1150428498
Containers:
ngxv2:
Image: 192.168.80.146:5000/my_ngx:v2
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
[root@k8s-master k8s-yaml]# kubectl rollout history deployment.v1.apps/ngx-deployment --revision=4
deployments "ngx-deployment" with revision #4
Pod Template:
Labels: app=ngx
pod-template-hash=1484039057
Containers:
ngxv2:
Image: 192.168.80.146:5000/my_ngx:v1
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
指定されたバージョンへのロールバック
[root@k8s-master k8s-yaml]# kubectl rollout undo deployment.v1.apps/ngx-deployment --to-revision=3
deployment.apps/ngx-deployment
拡張アップデート
命令扩展部署
kubectl scale deployment.v1.apps/ngx-deployment --replicas=6
启用自动扩缩
kubectl autoscale deployment.v1.apps/nginx-deployment --min=5 --max=10 --cpu-percent=80
一時停止と再開の展開
あなたは、展開を中断し、それを復元することができます。一時停止中に、展開への更新は、回復の展開を待って、すぐに実行されません。
kubectl rollout pause deployment.v1.apps/ngx-deployment
kubectl set image deployment.v1.apps/ngx-deployment nginx=nginx:1.9.1
kubectl rollout resume deployment.v1.apps/ngx-deployment
他の一般的なフィールドの展開命令は
.spec.revisionHistoryLimit古いさらにreplicaSet数を維持したい、この展開を指定します。バックグラウンドでのガベージコレクションの残りの部分。デフォルトでは、10です。展開がロールバックされませんので、明示的に0に設定し、このフィールドには、すべての歴史が展開清掃原因になります。
.spec.strategyポッドは、古いポリシーの交換のために指定され、再作成し、既存のすべてのポッドは、新しいポッドを作成する前に殺される。RollingUpdateロールオーバーポッド、あなたはmaxUnavailable maxSurge制御とロールオーバープロセスを指定することができます。
maxUnavailable、更新処理が定量化起動していない、値は絶対的であり得る（例えば、5）またはポッド（例えば、10％の割合を所望
maxSurge、更新プロセスは、ポッドの最大数を作成することができる。この値は絶対的であり得ます数（例えば、5）ポッドまたは所望のパーセンテージ（例えば、10％）
RSは、展開、管理制御を複数だけRSの現在の動作状態、他のコールドスタンバイ状態の存在することを確実にします。次のように灰色更新論理的な順序は次のとおりです。
DaemonSet
すべてのノード（または指定されたいくつかのノード）が指定されたポッドを実行していることを確認してください。新しいノードが自動的に指定されたポッドを実行します。ノードは、ポッドが回収され、すべてを終了し、DaemonSet削除、彼はポッドがクリアされます作成しました。
：一般的のような用途で使用されるノードレベル
- 、CEPHを各ノードで実行されているクラスタ化されたストレージ例えばデーモン、glusterdを実行します。
- 収集ログデーモン、例えばfluentd、logstash各ノード上で実行されています。
- 性能監視デーモン、例えばプロメテウスノード、輸出、collectdの各ノード
二つのモジュール：
セレクター：管理制御ポッド受け入れるように決定されるタグセレクタ、
テンプレート：新しいポッドを作成するためのポッドリソーステンプレートは、テンプレートは、方法は、リソース定義ポッドを参照して定義します
ポッドは、特定のノードでのみ実行します
- .Spec.template.spec.nodeSelectorフィールドを指定し、DaemonSetコントローラノードができるようになり
ポッドセレクタに一致するノードを作成します。 - .Spec.template.spec.affinityフィールドを指定し、DaemonSetコントローラノードアフィニティは、することができるであろう
ポッドノードマッチングを作成します。
あなたが指定されていない場合は、DaemonSetコントローラーは、すべてのノード上のポッドを作成します。
アップデートポリシー
DaemonSet更新ポリシー、2つの種類があります。
OnDelete：これは後方互換性のため、デフォルトのアップデートポリシーがあります。手動でのみ古いDaemonSetポッドを削除し、更新DaemonSetテンプレートの後、OnDelete更新ポリシーを使用している場合には、新たなDaemonSetポッドを作成します。これはDaemonSet行動の同じKubernetesバージョン1.5またはそれ以前です。
RollingUpdate：使用RollingUpdate更新戦略は、更新DaemonSetテンプレートの後に、古いDaemonSetポッドは、制御された方法で終了すると、自動的に新しいDaemonSetポッドを作成します。
ジョブ
ワンタイムタスクの実行を管理するためのポッド、通常の終了ポッド、自己治癒に対する通常の作業は発生しません。
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
cronジョブ
または定期的にのみポッド一度実行するために、時間のある時点でタスクを実行します
StatefullSet
管理ステートフルポッドへの適用は、いくつかの初期化プロセスがあります。作成されたポッドの展開は、ボリュームをマウントするときポッドがハングアップした場合の展開状態が再びボリュームをマウントすることはできません理由はないので、RSは、ポッドを再構築し、ステートレスです。
このような問題を解決するために、ポッドStatefulSetを保持するための状態情報の導入であって、シナリオ：
- 再スケジュールポッドまたは同じ永続的なデータへのアクセス後1、永続ストレージ安定、すなわち、PVCに基づく達成するために
二つの安定なネットワーク識別子、すなわちポッドをそのPodNameホスト名不変の再スケジュール、ベースのヘッドレスサービス（即ち、サービスなしCLUSTERIP）を達成
（すなわち、0からN-1次まで順次順次定義された順序に応じて展開または拡張するとき、すなわちポッドは、順序付けされた3、整然と配置、整然とした膨張ポッドポッドは、すべてが達成しinitcontainersに基づいて、）を実行すると、レディ状態される前に実行する必要があります前に
（4、秩序収縮をし、秩序が削除されたことを、N-1ダオ0）から
5と整然としたロールオーバー（バージョン互換性、ノードからの最初の更新）
StatefulSetは、次のコンポーネントで構成されています。
- ヘッドレスサービス（ヘッドレスサービス）はポッドのDNSレコードリソース識別子の決意を生成するために使用することができ、ポッドに直接DNSをしましょう。このように、ポッド内のドメイン名に直撃の流量。
- 静的または動的モード電源PVに基づいて、特定の固定ポッドストレージリソースを提供するためにvolumeClaimTemplatesストレージボリュームアプリケーションテンプレート（テンプレート作成PVC、PVCは各POD用のストレージ・ボリュームを生成する）、（ポッドが互いにアプリケーション、異なるストレージ・ボリュームを分散）。しかし、あなたは唯一のポッドテンプレートで同じストレージ・ボリュームを使用することができます。
- StatefulSet、リソース制御のためのポッド。
注意：StatefulSet并不能简单的适用于所有有状态的应用，仍需要用户自定义脚本处理相应的应用
削除statefulsetは、削除、PVC、その管理ポッドがvolumeClaimTemplates PVC名と再起動statefulsetに基づく関係を再確立しますしません。
ドメイン形式クラスタK8Sで：
pod_name.service_name.ns_name .svc.cluster.localマーク赤い部分が固定されています。
更新されたパーティションは、パーティション番号Nを指定し、シリアル番号がNに等しいより以上であるポッドが更新されるSTS
