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

Pod YAML 简要说明

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 会创建一个或者多个 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 的时候覆盖

通过 helm install 命令我们可以安装 chart 到 k8s 集群内，安装的时候可以通过指定 values.yaml 文件替换默认的参数，安装后应用在 helm 叫做 release

参考材料 & 推荐阅读

关注我获取更新

wechat

Kubernetes 是什么?

常用 Kubernetes 对象

Kubernetes 对象

Deployment

Statefulset

Helm 简介

参考材料 & 推荐阅读

关注我获取更新

Recommend

大降级时代：前年投消费，去年投芯片，今年投简历！

天舟五号货运飞船与空间站组合体完成自主快速交会对接

GameStop 将终止与 FTX.US 的合作，并向客户退款

Battle-Testing Nx Console with E2E Tests

京东新百货11.11尽显时尚生活热情 589个品类成交额同比增长超100%

The Next Hot Job: Pretending to Be a Robot

notmuch

.NET SqlClient 安全漏洞 CVE-2022-41064 解讀

新锐咖啡品牌直播喊麦走红，比雪王还洗脑的神曲诞生了？

祝贺！天舟五号发射任务成功|天舟五号_新浪科技_新浪网

About Joyk