一、rs
kubectl explain rs 查看rs模板信息
vim rs.yaml #粘贴上下面的yaml文件
kubectl create -f rs.yaml
kubcetl get pod
kubectl delete pod --all
kubcetl get pod --show-lables #查看Pod的标签
kubcetl lable pod fronted-m8hp tier=frontend1 --overwrite=True #对名称为fronted-m8hp的pod的标签进行更改
kubcetl get pod --show-lables #此时出现4个pod
kubectl delete rs--all #更改标签的pod已经不归rs管理，删不掉了
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec: #定义了ReplicaSet的规范
replicas: 3
selector:
matchLabels:
tier: frontend #表示该ReplicaSet将管理具有标签tier: frontend的Pod
template:
metadata:
labels:
tier: frontend
spec: #在template字段之内，用于定义Pod的规范
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
env:
-name: GET_HOSTS_FROM
value: dns
ports: #定义了容器需要暴露的端口。
- containerPort: 80
注：如果您不定义ports字段，Kubernetes仍然可以成功创建Deployment对象和Pod对象。但是，如果您希望从集群外部访问容器内的服务，或者希望通过Service对象进行负载均衡，那么您需要定义ports字段。
二、 Deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml - - record #record参数可以记录命令，方便查看revision的变化
（1）扩容
kubectl scale deployment nginx-deployment - -replicas10
如果集群支持horizontal pod autoscaling的话，还可以为Deployment设置自动拓展
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
（2）更新镜像
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
也可以使用edit命令来编辑 Deployment
kubectl edit deployment/nginx-deloyment
（3）回滚
kubectl rollout undo deployment/nginx-deployment
（4）更新策略
Deployment 可以保证在升级时只有一定数量的Pod 是down的。默认的，它会确保至少有比期望的Pod数量少一个是up状态(最多一个不可用)
Deployment 同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是up的(最多1个surge)
未来的kubernetes版本中，将从1-1变成25%-25%
kubectl describe deployment
（5）Rollover（多个rollout并行）
假如您创建了一个有5个niginx:1.7.9 replica的Deployment，但是当还只有3个nginx:1.7.9的replica创建出来的时候您就开始更新含有5个nginx:1.9.1 replica的Deployment。在这种情况下，Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod，并开始创建nginx:1.9.1的Pod。它不会等到所有的5个nginx:1.7.9的Pod都创建完成后才开始改变航道
（6）命令
kubectl rollout status deployments nginx-depliyment #用于检查指定Deployment的滚动更新状态。如果rollout成功完成，将返回一个0值的Exit Code
kubectl rollout history deployments nginx-depliyment #查看指定Deployment的滚动更新历史记录。
kubectl rollout history deployment/nginx-deployment # 查看指定Deployment的滚动更新历史记录。
deployment.extensions/nginx-deployment # 查看指定Deployment的滚动更新历史记录。
kubectl rollout undo deployment/nginx-deployment --to-revision=2 #将指定Deployment回滚到指定的修订版本。--to-revision=2：指定要回滚到的修订版本号为2。
kubectl rollout pause deployment/nginx-deployment #暂停指定Deployment的滚动更新过程。
（7）清理Policy
您可以通过设置.spec.revisonHistoryLimit项来指定deployment最多保留多少revision历史记录。默认的会保留所有的revision；如果将该项设置为0，Deployment就不允许回退了
三、Daemonset
DaemonSet 确保全部（或者一些） Node上运行一个Pod 的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod；
使用DaemonSet的一些典型用法：
运行集群存储 daemon，例如在每个Node上运行glusterd、ceph
在每个Node上运行日志收集daemon，例如 fluentd、logstash
在每个Node上运行监控daemon，例如 Prometheus Node Exporter、collectd、Datadog代理、New Relic 代理，或Ganglia gmond
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: deamonset-example #指定DaemonSet的名称为daemonset-example。
labels:
app: daemonset #为DaemonSet添加标签，其中app: daemonset是一个标签键值对。
spec:
selector: #定义了选择器，用于选择要在DaemonSet中运行的Pod
matchLabels:
name: deamonset-example
template: #定义了Pod的模板，用于创建DaemonSet中的Pod
metadata:
labels:
name: deamonset-example #为Pod添加标签，其中name: daemonset-example是一个标签键值对。
spec: #定义了Pod的规格
containers:
- name: daemonset-example
image: eang/myapp:v1
主节点上不会创建DaemonSet
注：通常情况下，DaemonSet的标签用于选择要管理的节点，而Pod的标签用于其他目的，例如选择器匹配、资源关联、服务发现等。例如，在一个具有多个节点的集群中，您可以为DaemonSet定义一个标签app: daemonset，用于选择所有参与DaemonSet的节点。然后，您可以为Pod定义另一个标签role: worker，用于标识Pod的角色或用途。
问题：DaemonSet、selector、template的lables 必须一样吗？
在DaemonSet配置中，selector和template的标签不一定要完全相同，但它们需要能够正确匹配以管理相应的Pod。
selector字段用于选择要由DaemonSet管理的Pod。它指定了一个或多个标签，这些标签必须与Pod的标签匹配，以确定是否由DaemonSet进行管理。这些标签在matchLabels字段中定义。
template字段定义了由DaemonSet创建的Pod的模板。在metadata.labels中，您可以定义用于标识Pod的标签。这些标签用于标识并选择由DaemonSet管理的Pod。
虽然selector和template的标签可以不完全相同，但它们需要有一些共同的标签来确保匹配。通常情况下，selector的标签应该是template标签的子集，以确保匹配正确的Pod。
例如，以下是一个示例配置文件，其中selector和template的标签有部分相同的标签：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-example
labels:
app: daemonset
spec:
selector:
matchLabels:
app: daemonset
env: production
template:
metadata:
labels:
app: daemonset
env: production
spec:
containers:
- name: daemonset-example
image: eang/myapp:v1
在此示例中，selector的标签包括app: daemonset和env: production，而template的标签也包括相同的标签。这样，DaemonSet将选择具有相同标签的Pod，并对其进行管理。
重要的是要确保selector和template的标签设置能够正确匹配并管理您想要的Pod。根据您的需求，您可以根据实际情况调整这些标签。
四、Job
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod 成功结束;
如下：这个配置文件创建了一个 Job，用于运行一个名为 "pi" 的 Pod，该 Pod 使用 "per1" 镜像运行一个 Perl 脚本命令，计算 pi 的值。一旦任务完成，Pod 将不会自动重启。
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template: #定义了要创建的 Pod 的模板
metadata:
name: pi #Pod 的名称
spec:
containers:
- name: pi #指定了容器的名称
image: per1
command: ["per1","-Mbigum=bpi","-wle","print bpi(2000)"]
restartPolicy: Never #指定了当 Pod 终止后的重启策略。在这里，设置为 "Never"，表示不会自动重启 Pod。
五、CronJob
Cron Job 管理基于时间的Job,即： * * * * * *
在给定时间点只运行一次
周期性的在给定时间点运行
使用前提: 当使用 Kubernetes 集群，版本 >= 1.8 （对CronJob）。对于先前版本的集群，版本< 1.8 ，启动API Server 时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启batch/v2alp1 API
典型的用法如下:
1、在给定的时间点调度Job运行
2、创建周期性运行的Job,例如: 数据库备份，发送邮件
注意：
restartPolicy 仅支持Never或OnFailure，不支持always（容器退出会重启pod）
spec.completions标志Job结束需要成功运行的pod个数，默认为1
spec.parallelism标志并行运行的pod个数，默认为1
spec.activeDeadlineSeconds标志失败pod的重试最大时间，超过这个时间不会继续重试
如下：这个配置文件创建了一个 CronJob，用于每分钟执行一个名为 "hello" 的 Job。该 Job 创建一个 Pod，其中的容器使用 "busybox" 镜像，在容器中执行命令打印当前日期和输出 "Hello"。如果任务执行失败，Pod 将会重启。
apiVersion: batch/v1bea1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *" #指定了任务执行的调度时间表达式。调度表达式是 "*/1 * * * *"，表示每分钟执行一次任务。
jobTemplate: #要创建的 Job 的模板
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello
restartPolicy: OnFailure
六、StatefulSet
StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：
1、稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
2、稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有
Cluster IP的Service）来实现
3、有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现有序收缩，有序删除（即从N-1到0）
七、Horizontal Pod Autoscaling
应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放
