ラベル（ラベル）
なぜ我々は、ラベルにそれを使用する必要がありますか？
よりよく管理するためにリソースの同じタイプのより多くのオブジェクトとして、単にリソース管理の効率を高めるために、1つのグループにラベルに従ってください。
lableは、ペアのオブジェクト（例えば、POD）に取り付けられています。あなたがオブジェクトを作成するときにオブジェクトが作成された後、あなたはまた、任意の時間を指定することができます指定することができます。システム自体の値にラベルとは意味がない、ユーザにのみ意味があります。
"labels": {
"key1" : "value1",
"key2" : "value2"
}文法と文字セット
Label key的组成：
* 不得超过63个字符
* 可以使用前缀，使用/分隔，前缀必须是DNS子域，不得超过253个字符，系统中的自动化组件创建的label必须指定前缀，kubernetes.io/ 由kubernetes保留。
* 起始必须是字母（大小写都可以）或数字，中间可以有连字符，下划线和点。Label value的组成:
不得超过63个字符
起始必须是字母（大小写都可以）或数字，中间可以有连字符，下划线和点。人気の、多次元ラベルの分類：
版本标签（release）： stable（稳定版），canary（金丝雀版本），beta（测试版）
环境类（environment）： dev（开发），qa（测试），production（生产），op（运维）
应用类（applaction）： ui（设计），as（应用软件），pc（电脑端），sc（网络方面）
架构层（tier）： frontend（前端），backend（后端），cache（缓存）
分区标签（partition）： customerA（客户），customerB
品控级别（track）： daily（每天），weekly（每周）次の例でラベルを練習するには：
[root@master yaml]# vim label-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: label-pod
labels: #使用labels字段来定义标签，可以一次定义多个标签，这里定义3个标签
release: stable #版本：稳定版
env: qa #环境：测试
tier: frontend #架构类：前端
spec:
containers:
- name: testapp
image: nginx #部署的是nginx服务
---
kind: Service #关联一个service资源对象
apiVersion: v1
metadata:
name: nginx-svc
spec:
type: NodePort
selector: #使用标签选择器
release: stable #只需定义selector字段中的一个标签，字段下的其他标签可全部实现关联。
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 32134[root@master yaml]# kubectl apply -f label-pod.yaml
pod/label-pod created
service/nginx-svc unchanged//查看所有pod，并且显示标签key:value：
[root@master yaml]# kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
label-pod 1/1 Running 0 30m env=qa,release=stable,tier=frontend値：//キーのポッドを指定して確認します。
[root@master yaml]# kubectl get pod label-pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
label-pod 1/1 Running 0 40m app=as,env=qa,release=stable,tier=frontend//表示のみ値ラベル：
[root@master yaml]# kubectl get pod label-pod -L env,release,tier
NAME READY STATUS RESTARTS AGE ENV RELEASE TIER
label-pod 1/1 Running 0 41m qa stable frontendラベル（コマンドライン）のその他の事業：ラベル、追加、変更、削除するために
、//コマンドラインを介してタグを追加します。
[root@master yaml]# kubectl label pod label-pod app=sc
pod/label-pod labeled
[root@master yaml]# kubectl get pod -L app
NAME READY STATUS RESTARTS AGE APP
label-pod 1/1 Running 0 36m sc//ラベルを変更します。
[root@master yaml]# kubectl label pod label-pod app=as
error: 'app' already has a value (sc), and --overwrite is false
[root@master yaml]# kubectl label pod label-pod app=as --overwrite
pod/label-pod labeledあなたは、修正--overwriteオプションを追加したいラベルを書き換える必要が見ることができます。
//ラベルを削除します。
[root@master yaml]# kubectl label pod label-pod app-
pod/label-pod labeled
[root@master yaml]# kubectl get pod -L app
NAME READY STATUS RESTARTS AGE APP
label-pod 1/1 Running 0 43m #可以看到该标签以被删除//私たちは、nginxのサービスの稼働時間かどうかを試験しました：
ラベルセレクタ
タグセレクタ：クエリのフィルタ条件タグ。
ラベルセレクタにより、同じオブジェクト番号のラベルを有していてもよく、ユニークなラベルではなく、クライアント/ユーザーは、ラベルセレクタのセットでコレクションオブジェクト、オブジェクトの動作を指定することもできます
現在、APIのサポートに2つのタグセレクタをkubernetes：
1）基于等值的关系(matchLables)： “=”，“==”，“!=”
2）基于集合的（matchExpressions）：in（在这个集合中），notin（不在这个集合中），exists（要么存在，要么不存在）使用タグセレクタ論理演算：
1）「と」操作のための複数のセレクタとの間の論理的関係を指定する
各リソース・オブジェクトが選択される意味、ヌルとタブセレクタ2）。
3）空のタグセレクタは、すべてのリソースを選出しないであろう。
4）コレクションの選択に基づいて、必須値文字列の空でないリストではなく、用途が存在するかDostNoteExists、その値がNULL値でなければなりません「の」または「Notin」操作を、使用。
例：
次のようにセレクタ操作の構文は次のとおりです。
[root@master yaml]# vim selector.yaml
selector:
matchLabels: #基于等值关系的
app: nginx
matchExpressions: #基于集合的
- {key: name,operator: In,values: [zhangsan,lisi]} #key，operator，values这三个是固定参数
- {key: age,operator: Exists,values:} #如果指定了Exists，其values值必须为空。Daemonset
1）Daemonsetは何ですか？
Daemonsetは必ず各クラスタノード上のポッドを実行する、とだけポッドを実行することができます。ノードが参加すると、クラスタは、彼らのためにポッドを追加します。ノードがクラスタから除去されると、ポッドを回収します。あなたが削除するとDaemonsetは、作成すべてのポッドを削除します。
注2）書き込みDaemonsetポイント：
Daemonsetは言葉遣い展開、RSと同じの他の資源ことを除いて、フィールドの複製はサポートされていません。
3）Daemonset一般的な使用シナリオ：
- 一般に、ログ収集の各ノードで使用されます。
- 各ノードの動作状態を監視します。
実践Daemonset：
[root@master yaml]# vim daemonset.yaml
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: nginx-ds
spec:
template:
metadata:
labels:
app: qa
env: dev
spec:
containers:
- name: nginx
image: nginx
---
kind: Service
apiVersion: v1
metadata:
name: nginx-dsvc
spec:
type: NodePort
selector:
app: qa
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30003[root@master yaml]# kubectl apply -f daemonset.yaml
daemonset.extensions/nginx-ds created
service/nginx-dsvc created//ポッドの分布を参照してください。
[root@master yaml]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-ds-dh429 1/1 Running 0 76s 10.244.2.2 node02 <none> <none>
nginx-ds-xz4d8 1/1 Running 0 76s 10.244.1.3 node01 <none> <none>私は、クラスタ内の2つのノードだけがポッドのコピーを実行する各ノード上で達成Daemonsetで見ることができています。
JOBリソースオブジェクト
リソースオブジェクトがサービスを提供し続けることである前に、異なるサービスクラスの前のコンテナ、。短時間の作業を担当するジョブの処理バッチは、そのタスクは、タスクまたは複数のポッド成功した結論を処理するバッチを保証し、一度だけ実行されます。
1、kubernetesは、次の仕事をサポートしています。
* 非并行job：通常创建一个pod直至其成功结束。
* 固定结束次数的job：设置spec.completions,创建多个pod，直到.spec.completions个pod成功结束。
* 带有工作队列的并行job：设置.spec.Parallelism但不设置.spec.completions,当所有pod结束并且至少一个成功时，job就认为是成功。2、ジョブコントローラ
ジョブコントローラは、ジョブ仕様に応じてポッドを作成する役割があり、それが正常に終了するまで、それが失敗した場合は、再度新しいポッド重量を作成するかどうかを決定する（だけONFAILUREと決してをサポートし、常にをサポートしていません）restartPolicyによると、ポッドの状態を監視し続けますテストタスク。
ジョブは、次の例によって実践：
//ジョブリソースオブジェクトを作成します。
kind: Job
apiVersion: batch/v1
metadata:
name: test-job
spec:
template:
metadata:
labels:
app: job
spec:
containers:
- name: job
image: busybox
command: ["echo","hello job!"]
restartPolicy: Never[root@master yaml]# kubectl apply -f job.yaml
job.batch/test-job created本番環境でのフィールドの使用を忘れた場合は、コマンドツールを説明kubectlことによって助けることができます。
//查看该pod资源对象的状态：
[root@master yaml]# kubectl get pod test-job-dcv6g
NAME READY STATUS RESTARTS AGE
test-job-dcv6g 0/1 Completed 0 2m8s私たちは、別のジョブおよびその他のリソースオブジェクトを参照して実行している夜を過ごすポッドデフォルトの終了後に1回だけタスク、つまり仕事を行うことができ、ステータスが完了しています。
タスクが完了したことを確認するために、ログを見て//ポッド：
[root@master yaml]# kubectl logs test-job-dcv6g
hello job!タスクが完了すると、他の要求ならば、我々は、ジョブを削除することができます。
[root@master yaml]# kubectl delete jobs.batch test-job
job.batch "test-job" deleted図2に示すように、ジョブの効率を改善するための方法は、
ファイルYAMLのフィールドを定義することによって達成されます。
kind: Job
apiVersion: batch/v1
metadata:
name: test-job
spec: #通过spec下的这两个字段来优化
parallelism: 2 #同时运行2个pod
completions: 8 #运行pod的总数量8个
template:
metadata:
labels:
app: job
spec:
containers:
- name: job
image: busybox
command: ["echo","hello job!"]
restartPolicy: Neverジョブフィールドの説明：
補完：仕事をポッドが正常に実行する必要がある番号の終わりをマークし、デフォルトは1である
並列：並列にポッドフラグランの数、デフォルトは1である
旗失敗時の再試行ポッドの最大時間、より多くのこの時間よりも、リトライに続行されません：activeDeadlineSecondsが。
//再実行ジョブの後、ポッドステータスを表示：
[root@master yaml]# kubectl get pod
NAME READY STATUS RESTARTS AGE
test-job-28ww5 0/1 Completed 0 50s
test-job-5wt95 0/1 Completed 0 46s
test-job-6s4p6 0/1 Completed 0 44s
test-job-8s2v7 0/1 Completed 0 50s
test-job-bt4ch 0/1 Completed 0 45s
test-job-bzjz6 0/1 Completed 0 48s
test-job-fhnvc 0/1 Completed 0 44s
test-job-kfn9l 0/1 Completed 0 48s
[root@master yaml]# kubectl logs test-job-28ww5
hello job!
私たちは、8のポッドの合計数を確認することができ、そして二つの平行な時間はほとんど差がありましたが、あまり。
3、仕事のタスクを実行する時間：
かなり私たちのタスクをLinuxのcrontabのプログラムで。
[root@master yaml]# vim cronjob.yaml
kind: CronJob #类型为CronJob
apiVersion: batch/v1beta1
metadata:
name: cronjob
spec: #使用spec.schedule字段来定义计划job任务
schedule: "*/1 * * * *" #指定每分钟执行一次任务，格式同linux中的crontab（分，时，日，月，周）
jobTemplate:
spec:
template:
spec:
containers:
- name: cronjob
image: busybox
command: ["echo","hello job!"]
restartPolicy: OnFailure #仅在pod失败时才重启//ポッド状態を監視YAMLファイルを実行した後：
[root@master yaml]# kubectl apply -f cronjob.yaml
cronjob.batch/cronjob created
私は、各実行は、ポッドを生成します、仕事のタスクを実行するために一人一人の分それを見ることができます。
ログを表示、タスクが実行することを確認します。
[root@master ~]# kubectl logs cronjob-1577505180-4ss84
hello job!
[root@master ~]# kubectl logs cronjob-1577505240-d5gf8
hello job!拡張：追加apiVersion
1）クラスタに対応するAPIのkubernetesの現在のバージョンを表示します。
[root@master ~]# kubectl api-versions
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
apps/v1beta1
apps/v1beta2
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1チェックには開発版、すべてのテストバージョンを見つかりませんでした。
APIバージョンを追加します。
[root@master ~]# cd /etc/kubernetes/manifests/
[root@master manifests]# ll
total 16
-rw------- 1 root root 1900 Nov 4 16:32 etcd.yaml
-rw------- 1 root root 2602 Nov 4 16:32 kube-apiserver.yaml
-rw------- 1 root root 2486 Nov 4 16:32 kube-controller-manager.yaml
-rw------- 1 root root 990 Nov 4 16:32 kube-scheduler.yaml
[root@master manifests]# vim kube-apiserver.yaml 
この分野では、上記のバッチ開発バージョンを追加して、バージョンに対応する対応フォーマットへの参照を追加します。
//重启kubelet，重新加载：
[root@master manifests]# systemctl restart kubelet.service再び// APIのバージョンを表示すると、あなたは開発バージョンを表示することができます。