k8s学习-运行应用

Deployment

Deployment是k8s最经常使用的controller，一般k8s不会直接建立pod，而是经过controller来管理POD的。Controller中定义了POD的部署特性，好比有几个副本，在什么样的NODE上运行等，它能够管理pod的多个副本，并确保pod按照指望的状态运行。

运行Deployment

按照以下方式，运行一个Deployment

kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=3

上面的命令将部署包含三个副本的Deployment nginx-deployment，容器的image为nginx:1.7.9

以下所示：

经过kubectl get deployment能够看到nginx-deployment的状态

经过kubectl describe deployment了解更详细的信息。

在NewreplicaSet，能够看到建立了一个nginx-deployment-754846b88c的replicatset，说明deployment是经过replicaset来管理POD的。执行kubectl describe replicaset 查看详细信息。

Controller By指明此ReplicaSet是由Deployment/nginx-deployment建立的。

执行kubectl get pod和kubectl describe pod查看更详细的信息。

Controlled By指明了POD由谁建立，EVENT记录了pod的启动过程。

整个过程以下所示：

1.用户经过 kubectl 建立 Deployment。

2.Deployment 建立 ReplicaSet。

3.ReplicaSet 建立 Pod。

对象命令的方式是”子对象的名字=父对象名字+随机字符串或者数字"

配置文件

1. 用 kubectl 命令直接建立，好比：

kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
在命令行中经过参数指定资源的属性。

2. 经过配置文件和 kubectl apply 建立，要完成前面一样的工做，可执行命令：

kubectl apply -f nginx.yml
nginx.yml 的内容为：

资源的属性写在配置文件中，文件格式为 YAML。

下面对这两种方式进行比较。

基于命令的方式：

简单直观快捷，上手快。

适合临时测试或实验。

基于配置文件的方式：

配置文件描述了 What，即应用最终要达到的状态。

配置文件提供了建立资源的模板，可以重复部署。

能够像管理代码同样管理部署。

适合正式的、跨环境的、规模化部署。

这种方式要求熟悉配置文件的语法，有必定难度。
kubectl apply 不但可以建立k8s资源，也能对资源进行更新，k8s还提供了kubectl create,kubectl reploace,kubectl edit和kubeclt path命令。

配置文件

配置文件主要是yaml格式，其余的controler跟deployment的配置文件方式相似

简单的配置文件以下所示：

① apiVersion 是当前配置格式的版本。
② kind 是要建立的资源类型，这里是 Deployment。
③ metadata 是该资源的元数据，name 是必需的元数据项。
④ spec 部分是该 Deployment 的规格说明。
⑤ replicas 指明副本数量，默认为 1。
⑥ template 定义 Pod 的模板，这是配置文件的重要部分。
⑦ metadata 定义 Pod 的元数据，至少要定义一个 label。label 的 key 和 value 能够任意指定。
⑧ spec 描述 Pod 的规格，此部分定义 Pod 中每个容器的属性，name 和 image 是必需的

执行kubectl apply -f niginx.yml便可。
执行kubectl delete deploymet nginx-deployment或者kubectl delete -f nginx.yml进行删除

伸缩

配置文件以下

伸缩是指在线增长或者减小Pod的副本数

初始是1个副本，以下所示：

如今修改new_nginx,yml文件，将副本修改为5个。

再次执行kubectl -f apply，结果以下所示：

在dashboard上也能确认

用label控制pod的位置

默认状况下,sxhedulet会将pod调度到全部可用的node上，不过有些状况须要将pod部署到指定的node上，k8s使用label来实现这个功能的。
label是key-value对，各类资源均可以设置label,灵活添加各类自定义的属性，以下所示，标注k8s-node1是配置了ssd的节点

kubectl label node docker-1 disktype=ssd

其余的node还有k8s本身维护的label
有了disktype这个自定义的label,接下来就能够指定将pod部署node-1上

在pod模板的spec里经过nodeSelector指定将此pod部署到具备label disktype=ssd的node上。

DaemonSet

Deployment部署的副本pod会分布在各个node上，每一个node均可以运行好几个副本。
DaemonSet的不通之处在于每一个node上最多只能运行一个副本。
它的典型应用场景有:
1.在集群的每一个几点上运行存储deamon，好比glusterd后者ceph
2.在每一个节点上运行日志收集deamon，好比flunentd或者logstash
3.在每一个几点上运行监控daemon，好比prometheus node exploer

其实k8s本身就在用DaemonSet运行系统组件

kube-proxy的配置文件，以下所示：

① kind: DaemonSet 指定这是一个 DaemonSet 类型的资源。

② containers 定义了 kube-proxy 的容器。

③ status 是当前 DaemonSet 的运行时状态，这个部分是 kubectl edit特有的。其实 Kubernetes 集群中每一个当前运行的资源均可以经过 kubectl edit 查看其配置和运行状态，好比 kubectl edit deployment nginx-deployment。

job

容器按照持续运行的时间可分为两类：服务类容器和工做类容器
服务类容器一般持续提供服务，须要一直运行，好比http server，daemon等，工做容器是一次性人物，好比批处理程序，完成后容器就退出
k8s的deployment,replicaSet和daemonset都用于管理服务类容器，对工做类容器，使用job
如下是个简单的job配置文件

① batch/v1 是当前 Job 的 apiVersion。

② 指明当前资源的类型为 Job。

③ restartPolicy 指定什么状况下须要重启容器。对于 Job，只能设置为 Never 或者 OnFailure。对于其余 controller（好比 Deployment）能够设置为 Always 。

经过 kubectl apply -f myjob.yml 启动 Job。

经过kubectl get job来查看job的状态

经过kubectl get pod查看pod的状态

由于Pod执行完毕后，容器已经退出，须要用--show all才能查看completed状态的pod,经过kubectl logs能够查看pod的标准输出。

job的并行性

在同时运行多个pod，能够提升job的执行效率，能够经过parallelism设置。

将并行的pod数量设置为2

定时job

linux中有cron程序定时执行任务，k8s的cronjob提供了相似的功能，能够执行job,配置文件以下所示：

① batch/v2alpha1 是当前 CronJob 的 apiVersion。

② 指明当前资源的类型为 CronJob。

③ schedule 指定何时运行 Job，其格式与 Linux cron 一致。这里 /1 * 的含义是每一分钟启动一次。

④ jobTemplate 定义 Job 的模板，格式与前面 Job 一致。