主要讲述如何在K8s中部署应用。
首先，我们在实战项目中经常会用到的一些概念
- Pod
- Deployment
- Service
- Namespaces
- DNS
使用上一篇文章，我们重建Kind K8s环境，并部署一个可以从本地访问的简单网页，加深理解。
环境(配置)
- centos7
- Docker 1.20
- kind
K8s部署应用相关概念
1. Workloads
Workloads（工作负载）是运行在K8s上的应用，可以是单独一个组件（比如一个Job）也可以是多个组件协同运行（比如deployment，service，ingress等一起构成一个应用）。
无论是哪种形式，在K8s上负载最终都是以Pod为基本单位运行的。
Pod本身有一个生命周期，比如当一个node出现故障宕机了，则此node上运行的所有Pod会失败，这时我们需要重新在其它节点创建Pod。
一般情况下，我们不直接运行Pod，我们通过Workloads Resources来帮我们管理Pod。
每个Workloads Resources有不同的controller相对应，controller按我们的要求维护Pod的状态（比如在一个node失败后，在其它节点重建pod）。
2. Pod
Pod是我们在K8s中可以创建使用的最小计算单元。每个Pod可以由一个或者多个容器组成。
比如，kube-system namespace内运行的pods
K8s为每个Pod分配一个集群内部的IP和DNS。
多个容器组成的Pods中，容器之间共享Pod的存储和网络。一个Pod中的多个容器总是安排运行在相同的node上，并且同时启动或者停止。
下图展示了一个Pod中运行的两个容器
- Web Server: 网站服务器，用来向用户提供访问网页
- FilePuller: Job服务，定期从另一个数据源下载文件到Pod内的存储中
Pod中多容器的常用应用例子还有
在Pod中运行应用容器之外，再运行一个Filebeat容器，用来把应用容器产生的日志输出到ElasticSearch。
下图中，第一行backend pod 中就运行了两个容器，READY 显示2/2，代表这个pod中有两个容器在运行
我们可以使用 kubectl describe 命令，查看 backend pod中具体有哪两个容器。
从下图可以看到，其中一个是backend应用容器，还有一个是filebeat容器
kubectl describe pods/POD_NAME -n NAMESPACE_NAME
另外，在Pod中我们还可以设置init容器，init容器在其它容器（应用容器）运行之前启动运行并终止，init容器可以帮我们做一些初始化的工作。
Workloads Resources
我们通过Workloads Resources来管理Pods，K8s提供了一些定义好的Workloads Resources类型来满足不同的业务要求。
- Deployment and ReplicaSet：适合管理无状态应用，Doployment中任意Pod都是可随意替换的。
- StatefulSet：有状态的应用场景，我们可以运行一个或多个相关连的Pods并记录其状态。
- DaemonSet：适合为cluster node提供服务的Pod，比如管理集群网络或者插件。当在K8s集群中新增Node时，由Control Plane根据DaemonSet中的定义安排在新的Node上运行Pod
- Job and CronJob：一次性任务的Pod。
Deployment
我们后面实验用的是Deployment，所以我们再多介绍一下Workloads Resources中的Deployment。
我们在Deployment中描述需要的状态，然后Deployment Controller帮我们把Pod运行在指定状态。
简单点说就是，我们在Deployment Yaml文件中定义自己的Pod（容器）模板、运行数量等，然后Deployment Controller帮我们维护这些Pod。
这时如果Pod运行所在的Node宕机了，Deployment Controller会自动帮我们把Pod运行到其它可用的Node上。
Deployment通过selector（利用labels）来选择哪些Pods归其管理。
下面就是一个Deployment Yaml文件，后面我们会用kubectl命令运行这个yaml文件，在kind K8s中部署。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80说明：
- .kind：定义这个K8s资源类型为Deployment
- .metadata.name：定义Deployment的名称是"nginx-deployment"
- .spec.replicas：指定运行三个同样的Pod
- .spec.selector：定义哪些Pod由这个Deployment来管理，这里选择Pod标签（labels）中带有"app: nginx"的。
- template：这里就是Pod模板
- .metadata.labels：给Pods定义标签"app: nginx"
- .template.spec：定义容器镜像的具体信息，公共仓库的nginx镜像，开放端口80
以后部署任何K8s应用，都会以这种yaml文件的形式来做部署。
当然我们也可以使用Helm来做部署，但Helm最终也是生成上面这种yaml文件来部署应用。
现在，我们观察一下Kind K8s中kube-system 空间内部署的Deployment
查看Deployment的详细信息
kubectl describe deployments/coredns -n kube-system
说明：这里可以看到selector，以及Pod模板等信息
3. Service
在用Deployment管理Pod时，Deployment会帮助我们重启失败的Pod，维护Pod设定的状态。
但是重启后的Pod会分配一个新的内部IP和DNS，这就会造成一些问题。
比如，一个应用运行了两组Pod，一组做为前端，另一组做为后端。当后端的Pod重启并分配新IP之后，前端如何找到新的后端？（服务发现）
这就是Service提供的功能。
Service用来把应用运行的Pods做为网络服务暴露出来。
可以简单理解为，Pods没有固定IP，但Service有固定IP，把Pods和Service关联起来之后，我们就可以通过Service来找到需要的Pods。
与Deployment一样，Service也用yaml文件来定义，下面一个Service的例子
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80说明：
- .kind: k8s资源类型为Service
- .metadata.name: 定义Service的名称，与Deployment类似
- .spec.selector：定义哪些Pod会关联到这个Service，这里选择Pod标签中带有"app: nginx"的，所以上面定义的Deployment中的Pods会关联到这个Service
- .spec.ports：这部分定义Service对外暴露的端口
- port: 这里Service会对外暴露80端口
- targetPort: Pods对Service暴露80端口 port和targetPort可以不同，也可以同时暴露多个端口
我们观察Kind K8s中kube-system 空间内部署的Service，目前这个Service的类型是Clsuter IP，只能从内部访问
4. Namespaces
K8s支持在cluster中创建virtual cluster，这些virtual cluster就叫做namespaces。
当一个K8s集群有很多用户或项目使用时，我们可以通过创建namespace来区分用户和资源。
在一个Cluster中，一个K8s对象的名称是不能重复的，但在namespace中，只要对象名称不在当前namespace中重复即可。
查看cluster中所有Namespaces
kubectl get namespaces
5. DNS
这里的DNS是特指K8s内部的DNS。K8s会自动为每个Pod和Service创建DNS，我们可以通过DNS或者IP来访问Pod和Service。