k8s-工作负载组件理解

最新推荐文章于 2024-03-20 14:44:00 发布

迷茫路人

最新推荐文章于 2024-03-20 14:44:00 发布

阅读量1k

点赞数

分类专栏： kubernetes 文章标签： kubernetes docker java

本文链接：https://blog.csdn.net/a1023934860/article/details/122256995

版权

kubernetes 专栏收录该内容

23 篇文章 3 订阅

订阅专栏

先来段官方语言压压惊

工作负载是在 Kubernetes 上运行的应用程序。
无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你 可以在一组 Pods 中运行它。在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器。
Kubernetes Pods 有确定的生命周期。例如，当某 Pod 在你的集群中运行时，Pod 运行所在的节点出现致命错误时，所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：即使该节点后来恢复正常运行，你也需要创建新的 Pod 来恢复应用。
不过，为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。相反，你可以使用负载资源来替你管理一组 Pods。这些资源配置控制器 来确保合适类型的、处于运行状态的 Pod 个数是正确的，与你所指定的状态相一致。

注意上面的加粗字体，我认为这基本上就能够概括工作负载的功能了（控制器保证pod正确)（应用程序实现一定功能）

k8s内置工作负载资源有:
Deployment,ReplicaSet
StatefulSet
DaemonSet
Job 和 CronJob

Deployment

他们本质就是一个个写好的控制器，只不过他们被集成到了k8s里面，不需要我们自己开发。
那么控制器的本质是什么，就是采用informer监控资源然后作出一系列的动作(informer的机制就是监听然后触发特定的方法)。

就拿Deployment来说，首先获取所有的资源，然后通过自己的ymal配置文件寻找要监控的pod资源，然后进行比对是否与配置文件里面的资源预期一样，如果不一样则进行一些列的策略让其趋近相同。比如创建了一个Deployment监控student Pod，配置文件里面设置副本为3个，但是实际启动了两个，那么Deployment就会向etcd(其实是向apiserver发送指令，但是apiserver也是向etcd进行操控)写入一条资源，调度器监控到student 这个资源进行了改变(添加) 那么调度器会通过调度策略寻找合适的node运行pod。

所以在开发控制器的时候，设计informer是必不可少的(现在可以通过代码生成生成informer)

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: student
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: student
    spec:
      containers:
      - name: student
        image: student:1.0.1
        ports:
        - containerPort: 8080

StatefulSet

一般的服务器都可以是无状态服务，但是需要有状态服务时该怎么办，StatefulSet控制器就解决这个问题。
首先我们了解它提供了几个功能

稳定的持久化存储 (提供了存储服务，比如往nginx里面存放静态页面)
稳定的网络标志 (Pod重新调度后其PodName和HostName不变) 这个采用Headless Service来实现，这里需要了解k8s网络才能更好的明白
有序部署，有序扩展。就是创建的pod是有顺序的(表现在他的name上)，只有前面的状态是Running和Ready，当前pod才能运行。这个使用init containers来实现(我认为就是一个容器运行前置处理器)

当我们删除pod时，所连接的pvc不会被删除，反而会在重新创建pod 的时候进行连接使用。

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

DaemonSet

这个控制器有些特殊，它功能是，收集各个node日志，并监控每个node里面的组件等。所以它需要在每个node都创建一个pod副本进行工作。
在1.11之前的版本，它是不受调度控制器控制的因为没什么可计算的。但是为了pod的定义完成性，在之后不再自动添加.spec.nodeName，而是以nodeAffinity

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name