Kubernetes 简明教程

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

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

目标

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

Kubernetes 是什么?

  • Kubernetes 是一个可移植、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置自动化

  • Kubernetes 可以做什么:

    • 服务发现和负载均衡
    • 存储编排
    • 自动部署和回滚
    • 自动完成装箱计算
    • 自我修复
    • 密钥与配置管理
  • Kubernetes 架构

    image

    Kubernetes 是一个典型的主从架构,对于用户而言其实都是在和 Kubernetes Master 的 API 打交道,无论大家是通过 kubectl 这种 cli 工具,还是说通过 Kubernetes Dashboard 等 UI 界面,还是通过 client-go sdk 进行开发都是一样

常用 Kubernetes 对象

Kubernetes 对象

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

  • Pod YAML 简要说明

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

    以我们的 api-svc 服务为例

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    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 也是随机的

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    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 区别不是很大

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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 的基本结构

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    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
知乎
github

猜你喜欢