资源创建方式

kubernetes支持两种创建资源的方式：
1. 用kubectl命令直接创建，比如：kubectl run nginx-deployment --image=nginx1.7.9 --replicas=2，在命令行中通过参数指定资源的属性
2. 通过配置文件和kubectl apply创建，创建nginx.yml文件，然后运行命令：kubectl apply -f nginx.yml
3. 比较：
  1. 基于命令的方式：简单，直观，快捷，上手快
  2. 基于配置文件的方式：配置文件描述了最终要达到的状态，提供了创建资源的模板，能够重复部署，可以像管理代码一样管理部署，适合正式的，跨环境的，规模化部署
配置文件介绍：
1. apiVersion: extensions/v1beta1：apiVersion是当前配置格式的版本
2. kind: Deployment：kind是要创建的资源类型，这里是Deployment
3. metadata：是该资源的元数据，name是必须的元数据项
4. spec：是该Deployment的规格说明
5. replicas：指明副本数量，默认为1
6. template：定义Pod的模板，这是配置文件的重要部分
7. metadata：定义Pod的元数据，至少要定义一个label，label的key和value可以任意指定
8. spec：描述Pod的规格，此部分定义Pod中每一个容器的属性，name和image是必须的
删除资源：执行kubectl delete deployment nginx-deployment或者kubectl delete -f nginx.yml
伸缩：
1. 伸缩是指在线增加或减少Pod的副本数
2. Deployment nginx-deployment初始是两个副本，k8s-node1和k8s-node2各跑了一个副本，现在修改nginx.yml文件，将副本数改为5个
3. 再次执行kubectl apply，进行应用的部署，然后执行kubectl get pod -o wide查看pod状态，调度器会根据集群的资源和指定的调度策略（如亲和性规则、亲缘关系和反亲缘性）来选择合适的节点分配pod副本
4. 三个副本被创建并调度到节点1和节点2上，出于安全考虑，默认配置下kubernetes不会将Pod调度到Master节点上，如果希望将master也当做Node使用，可以执行命令：kubectl taint node k8s-master node-role.kubernetes.io/master- 。如果要回复Master node only状态，执行命令：kubectl taint node k8s-master node-role.kubernetes.io/master=“”:NoSchedule
Failover:
1. 模拟k8s-node2故障，关闭该节点，等待一段时间后，kubernetes会检查到k8s-node2不可用，将k8s-node2上的pod标记为Unknown状态，并在k8s-node1上新创建k8s-node2上的数量的pod，维持副本数不变
2. 当k8s-node2恢复后，Unknown的Pod会被创建，不过已经运行的Pod不会重新调度回k8s-node2
用label控制pod的位置
1. 默认配置下，scheduler会将pod调度到所有可用的node，不过如果将有大量磁盘IO的pod部署到配置了SSD的Node，或者Pod需要GPU，需要运行在配置了GPU的节点上，希望将Pod部署到指定的Node上
2. kubernetes通过label来实现这个功能
3. label是key-value对，各种资源都可以设置label，灵活添加各种自定义属性，比如执行命令标注k8s-node1是配置了SSD的节点
4. kubectl label node k8s-node1 disktype=ssd，然后通过kubectl get node --show-labels查看节点的label
5. 部署pod到node1：在pod模板中，spec中通过nodeSelector指定将次pod部署到具有label disktypessd的Node上
6. 部署Deployment并查看Pod的运行节点，可以看到全部6个副本都运行在node1上
7. 删除label disktype命令：kubectl label node k8s-node1 disktype- 这个- 就是删除的意思。不过此时的Pod并不会重新部署，依然在k8s-node1上运行。除非在nginx.yml中删除nodeSelector设置，然后通过kubectl apply重新部署。kubernetes会删除之前的Pod并调度和运行新的Pod
DaemonSet：
1. Deployment部署的副本Pod会分布在各个Node上，每个Node都可能运行好几个副本，DaemonSet的不同之处在于：每个Node上最多只能运行一个副本
2. DaemonSet的应用场景有：
  1. 在集群的每个节点上运行存储Daemon，比如glusterd或者ceph分布式存储系统
  2. 在每个节点上运行日志收集Daemon，比如flunentd或者logstash
  3. 在每个节点上运行监控Daemon，比如Prometheus Node Exporter或者collectd
3. kubernetes自己就在用DaemonSet运行系统组件，执行命令：kubectl get daemonset --namespace=kube-system
4. 查看详细信息：kubectl get pod --namespace=kube-system -o wide
5. 因为flannel和kube-proxy属于系统组件，需要在命令行中通过–namespace=kube-system指定namespace指定namespace kube-system，若不指定，则只返回默认namespace default中的资源
kube-flannel-ds：
1. 部署flannel网络的命令：kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml。
2. flannel的DaemonSet就定义在kube-flannel.yml中
3. 配置解析
  1. DaemonSet配置文件的语法和结构与Deployment几乎完全一样，只是将kind设为DaemonSet
  2. hostNetwork指定Pod直接使用的是Node网络，相当于docker run --network=host
  3. containers定义了运行flannel服务的两个容器
kube-proxy：
1. 通过命令：kubectl edit daemonset kube-proxy --namespace=kube-system查看配置
2. 配置解析：
  1. kind：DaemonSet指定这是一个DaemonSet类型的资源
  2. containers定义了kube-proxy的容器
  3. status是当前DemonSet的运行时状态，这个部分是kubectl edit特有的，
  4. kubernetes集群中每个当前运行的资源都可以通过kubectl edit查看其配置和运行状态，比如：kubectl edit deployment nginx-deployment
Job:
1. 容器按照持续运行的时间可分为两类，服务类容器，和工作类容器
2. 服务类容器通常持续提供服务，需要一直运行，比如HTTP,Server，Daemon等，
3. 工作类容器则是一次性任务，比如批处理程序，完成后容器就退出
4. kubernetes的Deployment，ReplicaSet和DaemonSet都用于管理服务类容器，对于工作类容器，使用Job
5. myjob.yam配置解析
  1. batch/v1是当前Job的apiVersion
  2. 指明当前资源的类型为Job
  3. restartPolicy指定什么情况下需要重启容器，对于Job，只能设置为Never或者OnFailure，对于其他controller，比如Deployment，可以设置为Always
  4. 通过kubectl apply -f myjob.yml启动Job
6. 通过kubectl get job 查看Job的状态
  1. desired和successful都为1，表示按照预期启动了一个pod，并且已经成功执行，通过kubectl get pod 查看pod的状态
  2. 因为pod执行完毕后容器已经退出，需要用–show-all才能看到Completed状态的Pod
  3. 通过kubectl logs可以查看Pod的标准输出