Kubernetes 简明教程

注：本文已发布超过一年，请注意您所使用工具的相关版本是否适用

注：本文所有示例代码都可以在 blog-code 仓库中找到

目标

本文面向平时工作中会使用到 Kubernetes 但是又对其不是怎么了解的开发者
本文只对大家平时在使用 Kubernetes 中会碰到的常用概念做一个简单介绍，不会过多的阐述架构原理上的一些东西
希望阅读完这篇文章后，大家可以对 kubernetes 的概念有相关了解，并且了解一些简单的运维操作
如果想要深入学习，可以查看本文最后的推荐阅读部分

Kubernetes 是什么?

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。
Kubernetes 可以做什么:
- 服务发现和负载均衡
- 存储编排
- 自动部署和回滚
- 自动完成装箱计算
- 自我修复
- 密钥与配置管理
Kubernetes 架构
Kubernetes 是一个典型的主从架构，对于用户而言其实都是在和 Kubernetes Master 的 API 打交道，无论大家是通过 kubectl 这种 cli 工具，还是说通过 Kubernetes Dashboard 等 UI 界面，还是通过 client-go sdk 进行开发都是一样

常用 Kubernetes 对象

Kubernetes 对象

apiVersion: v1
kind: Pod

# 元数据
metadata:
  name: nginx
  namespace: dev
  labels:
    a: b

# 对象的规格（Spec）描述了某一个实体的期望状态
spec:

# 对象的状态
status:

apiVersion 对象的版本
kind 对象类型
metadata 对象元数据
- namespace 对象的命名空间
  - 可以通过 namespace 来隔离对象
  - 我们也可以对用户进行授权只能访问一些特定 namespace 的对象，以实现多租户的一些功能
  - 当然不是所有的对象有存在 namespace，也存在部分对象是 cluster 级别的
- name 对象的名字，对象的名字在一个 namespace 内是唯一的，我们可以通过 namespace + name 获取到一个具体的对象
- labels 标签
  - 我们可以通过 labels 对 Kubernetes 的对象进行分类，也可以使用 kubectl 时快速的通过 labels 筛选对象 kubectl get pods -l a=b
  - 同样，其他对象也可以通过标签选择器(labelSelector) 关联对象，例如 Deployment 就是通过标签选择器关联了对应的 Pod
spec 对象的规格（Spec）描述了某一个实体的期望状态
- 每一个对象的 Spec 基本都是由开发或者维护当前对象的工程师指定的
- 这也是 Kubernetes 声明式配置的主要表现，用户提交了期望的配置后，Kubernetes 内对应的 Controller 就会尽可能的去达到用户所期望的状态
status 对象的状态信息描述了当前对象的所处的状态
- 和 spec 类似每个对象的 status 都是工程师定义的，所以每个对象的 status 对象都各不相同

Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
Pod 是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器
- Init 容器会在 Pod 的应用容器启动前完成
- 所以一般我们会使用 Init 容器来完成一些初始化的操作，例如执行 DB Migrate，下载需要的配置文件等等
如下图所示，Pod 可以共享网络和存储，所以一个 Pod 内的多个容器可以直接通过 127.0.0.1 互相访问

Pod YAML 简要说明

1	`kubectl --context bcs-test -n develop get pods`

以我们的 api-svc 服务为例

apiVersion: v1
kind: Pod
metadata:
  labels:
    app.kubernetes.io/chart: trpc
    app.kubernetes.io/name: api-service
  name: api-service-deploy-6b8cdb5dc8-rzg6m
  namespace: develop
spec:
  # 亲和性配置，可以约束 pod 能调度到哪些节点
  # 这项配置可以实现 pod 调度到指定节点
  # 也可以让一些有相同标签等字段的 Pod 尽量调度在一起或者不在一起
  # 比较常用的一个做法是，让 Pod 尽量不处于一个可用区，这样即使云服务商的一个可用区机房挂了我们也能对外提供服务
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            a: "b"
        topologyKey: kubernetes.io/hostname

  # 存储卷声明
  # 这里我们声明了一个 empty dir 的存储卷，可以理解为就是一个临时的空目录
  # 这个卷会在 pod 销毁后自动销毁
  volumes:
  - emptyDir: {}
    name: config-cache

  # 初始化容器
  initContainers:
  - image: init:20220401221741
    imagePullPolicy: IfNotPresent
    name: init-trpc-go-config
    # 这个初始化容器和下面的应用容器都挂载了这个 empty dir
    # 所以这两个容器可以对这同一个目录进行读写
    volumeMounts:
    - mountPath: /app/config/
      name: config-cache
  
  # 容器配置
  containers:
  - command:
    - /app/api_service
  
    # 环境变量，除了指定 kv 之外
    # 也可以像下面这样把 pod 本身的一些字段通过环境变量的方式注入到容器内
    env:
    - name: env
      value: develop
    - name: pod_ip
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: status.podIP
    image: api-service:master-5f05c18a
    # 容器镜像的下载方式
    imagePullPolicy: IfNotPresent

    # 生命周期 hook
    # 下面这个例子是在容器退出前先 sleep 120s
    # 这是为了能够让我们的注册中心能够有时间把服务踢下线，避免我们在发布的时候中断
    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sh
          - -c
          - sleep 120
  
    # 存活检查
    # 如果不满足下面的健康检查，pod 就会被自动终止
    livenessProbe:
      failureThreshold: 1
      httpGet:
        path: /cmds
        port: 8000
        scheme: HTTP
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1

    name: api-service

    # 端口映射
    ports:
    - containerPort: 8001
      hostPort: 29131
      protocol: TCP

    # 资源限制
    resources:
      limits:
        cpu: "1"
        memory: 2Gi
      requests:
        cpu: 50m
        memory: 50Mi
    volumeMounts:
    - mountPath: /app/config/
      name: config-cache
status:

Deployment

Deployment 常用于管理无状态的服务，例如常见的 web 后端服务几乎都是无状态的，Deployment 启动 pod 时没有特别顺序，每个 pod 的 name 也是随机的

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    meta.helm.sh/release-name: api-service
    meta.helm.sh/release-namespace: develop
  labels:
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: api-service
  name: api-service-deploy
  namespace: develop
spec:
  # 副本数
  replicas: 2
  # 标签选择器，表示这个 Deployment 控制这些 pod
  selector:
    matchLabels:
      app.kubernetes.io/name: api-service
  # 更新策略
  strategy:
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 0%
    type: RollingUpdate
  # pod template，其实就是 pod 的定义，除了不用填写  apiVersion 和 kind 没有任何区别
  template:
    metadata:
      labels:
        app.kubernetes.io/name: api-service
    spec:
      # pod spec
status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: "2022-11-02T04:52:37Z"
    lastUpdateTime: "2022-11-02T09:56:06Z"
    message: ReplicaSet "api-service-deploy-6b8cdb5dc8" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 290
  readyReplicas: 2
  replicas: 2
  updatedReplicas: 2

Statefulset

StatefulSet 是用来管理有状态应用的工作负载 API 对象，StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。
- StatefulSet 启动 Pod 时总是按顺序启动，pod 的名字也是固定的，可以直接通过 pod 的 name 作为域名访问 pod

StatefulSet YAML 和 Deployment 区别不是很大

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默认值是 1
  minReadySeconds: 10 # 默认值是 0
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      # pod spec

Job

Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。当数量达到指定的成功个数阈值时，任务（即 Job）结束。删除 Job 的操作会清除所创建的全部 Pod。挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。
Job 一般常用于一些一次性的任务，例如对战任务等等等等

Job YAML

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Helm 简介

我们在部署一个 kubernetes 应用的时候往往会涉及到很多的对象，在很多个应用部署的时候往往只有有限的字段需要修改，如果所有的部署都采用 yaml 的方式，会导致有大量的重复字段，以及带来十分低效的维护方式。
helm 就是其中一种解决方式，它可以用来管理 chart，chart 是易用 k8s 应用包管理方式，主要就是很多的 yaml 模板文件再加上一个 values.yaml 文件用于定义输入字段

chart 的基本结构

mychart
├── Chart.yaml
├── charts # 该目录保存其他依赖的 chart（子 chart）
├── templates # chart 配置模板，用于渲染最终的 Kubernetes YAML 文件
│   ├── NOTES.txt # 用户运行 helm install 时候的提示信息
│   ├── _helpers.tpl # 用于创建模板时的帮助类
│   ├── deployment.yaml # Kubernetes deployment 配置
│   ├── ingress.yaml # Kubernetes ingress 配置
│   ├── service.yaml # Kubernetes service 配置
│   ├── serviceaccount.yaml # Kubernetes serviceaccount 配置
│   └── tests
│       └── test-connection.yaml
└── values.yaml # 定义 chart 模板中的自定义配置的默认值，可以在执行 helm install 或 helm update 的时候覆盖