kubernetes支持两种创建资源的方式：

1、基于命令的方式

kubectl run nginx-deployment —image=nginx:1.7.9 —replicas=2
简单、直观、快捷，上手快
适合临时测试或实验

2、基于配置文件的方式

kebectl apply -f nginx.yml #nginx.yml中包含资源属性配置，文件格式为YAML
配置文件描述了what，即应用最终要达到的状态。
配置文件提供了创建资源的模板，能够重复部署
可以像管理代码一样管理部署
适合正式的、跨环境的、规模化的部署
这种方式要求熟悉配置文件的语法，有一定难度

Deployment配置文件简介

K8s学习笔记-3/25 - 图1
K8s学习笔记-3/25 - 图2
1、apiVersion：apps/v1 #当前配置格式的版本
2、kind #要创建的资源类型，这里是Deployment
3、metadata #该资源的元数据，name是必须的元数据项
4、spec #Deployment的规格说明
5、replicas #副本数量，默认为1
6、selector #标签选择器
7、template #pod模板
8、metadata #pod元数据
9、spec #pod规格
10、container #容器配置

伸缩

伸缩是指在线增加或减少Pod的副本数。
通过修改yml文件中的replicas值，来增加减少副本数量。
修改后执行kubectl apply -f xxx.yml

如果k8s-master也当作Node使用，可以执行一下命令：
kubectl taint node k8s-master node-role.kubernetes.io/master-
恢复命令：
kubectl taint node k8s-master node-role.kubernetes.io/master=””:NoSchedule

Failover

模拟k8s-node2故障，关闭该节点，k8s-node2上的pod标记为Unknown状态
k8s-node1会创建新的pod维持副本数，当k8s-node2恢复后Unknown的pod会被删除，不过已经运行的pod不会重新调度回k8s-node2

DaemonSet

一个DaemonSet确保了所有的node上仅有一个的Pod的一个实例。当node被添加到集群中，Pod也被添加上去。当node被从集群移除，这些Pod会被垃圾回收。删除一个DaemonSet将会清理它创建的Pod。
举一些DaemonSet典型用法的例子：

  • 在每个node上运行一个集群存储守护进程，例如glusterd、ceph
  • 在每个node上运行一个日志集合，例如fuentd或者logstash
  • 在每个node上运行一个node监控后台线程，例如Prometheus Node Exporter，collectd，Dynatrace OneAgent，AppDynamics Agent，Datadog agent，New Relic agent，Ganglia gmod 或者Instana agent.

Job

Job负责批量处理短暂的一次性任务（short lived one-off tasks），即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。

Job Spec格式

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时，默认Pod成功运行后Job即结束
  • .spec.completions标志Job结束需要成功运行的Pod个数，默认为1
  • .spec.parallelism标志并行运行的Pod的个数，默认为1
  • spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

kubernetes支持一下几种Job：
#非并行Job：通常创建一个Pod直至其成功结束
#固定结束次数的Job：设置.spec.completions，创建多个Pod，直到.spec.comlettions个Pod成功结束
#带有工作队列的并行Job:设置.spec.Parallelielism但不设置.spec.comlettions，当所有Pod结束并且至少一个成功时，Job就认为成功
查看Job的状态命令
kubectl get job

CronJob

CronJob即定时任务，类似于Linux系统的crontab，在指定的时间周期运行指定的任务。

CronJob Spec

  • .spec.schedule指定任务运行周期，格式同Cron
  • .spec.jobTemplate指定需要运行的任务，格式同Job
  • .spec.startingDeadlineSeconds指定任务开始的截止期限
  • .spec.concurrencyPolicy指定任务的并发策略，支持Allow、Forbid和Replace三个选项

Service

Kubernetes Service 从逻辑上代表了一组Pod，具体是哪些Pod则是由label来挑选的。
Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化，对客户端不会有任何影响，因为Service没有变。

外网如何访问Service

（1）ClusterIP
Service通过Cluster内部的IP对外提供服务，只有Cluster内的节点和Pod可访问，这是默认的Service类型
（2）NodePort
Service通过Cluster节点的静态端口对外提供给服务。Cluster外部可以通过:访问Service。
（3）LoadBalancer
Service利用cloud provider特有的load balancer对外提供服务，cloud provider负责将load balancer的流量导向Service。

flannel网络

flannel可以让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址,使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
flannel的作用有以下几点:
1.使集群中的不同Node主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
2.建立一个覆盖网络（overlay network），通过这个覆盖网络，将数据包原封不动的传递到目标容器。覆盖网络是建立在另一个网络之上并由其基础设施支持的虚拟网络。覆盖网络通过将一个分组封装在另一个分组内来将网络服务与底层基础设施分离。在将封装的数据包转发到端点后，将其解封装。
3.创建一个新的虚拟网卡flannel0接收docker网桥的数据，通过维护路由表，对接收到的数据进行封包和转发（vxlan）。
4.etcd保证了所有node上flanned所看到的配置是一致的。同时每个node上的flanned监听etcd上的数据变化，实时感知集群中node的变化。

Rolling Update

滚动更新是一次只更新一小部分副本，成功后在更新多的副本，最终完成所有副本的更新。
滚动更新的最大好处是零停机，整个更新过程始终有副本在运行，从而保证了业务的连续性。

回滚

kubectl apply每次更新应用时，kubernetes都会记录下当前的配置，保存为一个revision（版次）。这样就可以回滚到某个特定revision。
默认配置下，kubernetes只会保留最近的几个revision，可以在Deployment配置文件中通过revisionHistoryLimit属性增加revision数量。
kubectl apply -f httpd.v1.yml —record #第一次更新
kubectl apply -f httpd.v2.yml —record #第二次更新
kubectl apply -f httpd.v3.yml —record #第三次个更新
查看revision历史记录
kubectl rollout history deployment httpd
回滚到某个版本
kubectl rollout undo deployment httpd —to-revision

Volume

Volume的生命周期独立与容器，Pod中的容器可能被销毁和重建，但Volume会被保留。
Kubernetes Volume是一个目录，这点与Docker Volume类似。当Volume被mount到Pod，Pod中的所有容器都可以访问这个Volume。
Kubernetes Volume也支持多种backend类型，包括emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph等。

  1. containers:
  2.     - image: 'nginx:1.20.2-alpine'
  3.       imagePullPolicy: IfNotPresent
  4.       name: nginx
  5.       ports:
  6.         - containerPort: 80
  7.           protocol: TCP
  8.       resources: {}
  9.       terminationMessagePath: /dev/termination-log
  10.       terminationMessagePolicy: File
  11.       volumeMounts:
  12.         - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
  13.           name: default-token-54sbw
  14.           readOnly: true

emptyDir

emptyDir是Host上创建的临时目录，其优点是能够方便地为Pod中容器提供共享存储，不需要额外的配置。它不具备持久性，如果Pod不存在了，emptyDir也就没有了。根据特性，emptyDir特别适合Pod中的容器需要临时共享存储空间的场景。

hostPath

hostPath Volume的作用是将Docker Host文件系统中已经存在的目录给Pod的容器。大部分应用都不会使用hostPath Volume，因为这实际上增加了Pod与节点的耦合，限制了Pod的使用。那些需要访问Kubernetes或Docker内部数据（配置文件和二进制库）的应用则需要使用hostPath。

PersistentVolume&PersistentVolumeClaim

PersistentVolume（PV）是外部存储系统中的一块存储空间，由管理员创建和维护。与Volume一样，PV具有持久性，生命周期独立于Pod。
PersistentVolumeClaim（PVC）是对PV的申请（Claim）。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时，用户可以创建一个PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes会查找并提供满足条件的PV。

kubectl相关命令

创建一个应用
kubectl create deployment kubernetes-bootcamp —image=gcr.io/google-samples/kubernetes-bootcamp:v1

查看应用
kubectl get deployments

查看pods
kubectl get pods

描述pods
kubectl describe pods

运行一个应用
kubectl run nginx-deployment —image=nginx:1.7.9 —replicas=2