K8S系列文章之服务部署核心概念

news2024/11/14 13:27:26

主要讲述如何在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，只能从内部访问