K3s 日常使用备忘录

49 minute read

术语

  • 节点(Node): Kubernetes 集群中的一台工作机器,是集群的一部分。
  • 集群(Cluster): 一组运行由 Kubernetes 管理的容器化应用程序的节点。在此示例和在大多数常见的 Kubernetes 部署环境中,集群中的节点都不在公共网络中。
  • 边缘路由器(Edge Router): 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关,也可以是物理硬件。
  • 集群网络(Cluster Network): 一组逻辑的或物理的连接,根据 Kubernetes 网络模型在集群内实现通信。
  • 服务(Service):Kubernetes 服务(Service),使用标签选择器(selectors)辨认一组 Pod。除非另有说明,否则假定服务只具有在集群网络中可路由的虚拟 IP。

负载分类

  • Deployment
    • 无状态,所有 Pod 等价,可替代。
  • StatefulSet
    • 有状态,适合诸如数据库等应用。
  • DaemonSet
    • 每个节点上跑一个 Pod,适合用来做节点监控、节点日志收集等
  • Job & CronJob
    • Job 表示一次性的任务,CronJob 表示定时任务。

常用命令

Deployment

 1# 查看部署
 2sudo kubectl get deployment
 3# 部署应用
 4sudo kubectl apply -f <deployment-file>
 5# 伸缩扩展副本
 6sudo kubectl scale deployment <deployment-name> --replicas=5
 7# 查看历史
 8sudo kubectl rollout history deployment <deployment-name>
 9# 回到上个版本
10sudo kubectl rollout undo deployment <deployment-name>
11# 回到指定版本
12sudo kubectl rollout undo deployment <deployment-name> --to-revision=2
13# 删除部署
14sudo kubectl delete deployment <deployment-name>
15# 重新部署
16sudo kubectl rollout restart deployment <deployment-name>
17# 命令修改镜像, 末尾 --record 表示把当前命令记录到操作历史中
18# 此处命令表示修改指定部署中容器名称为 test-k8s 容器使用的镜像
19sudo kubectl set image deployment <deployment-name> test-k8s=ccr.ccs.tencentyun.com/k8s-tutorial/test-k8s:v2-with-error --record
20# 输出到文件
21sudo kubectl get deployment <deployment-name> -o yaml >> app2.yaml
22# 暂停应用
23# 暂停后,对 deployment 的修改不会立刻生效,恢复后才应用设置
24sudo kubectl rollout pause deployment <deployment-name>
25# 恢复应用
26sudo kubectl rollout resume deployment <deployment-name>

Pod

 1# 查看 pod
 2sudo kubectl get pod -o wide
 3# 查看 pod 详情
 4sudo kubectl describe pod <pod-name>
 5# 查看 pod 日志
 6sudo kubectl logs <pod-name>
 7# 删除 pod
 8sudo kubectl delete pod <pod-name>
 9# 进入 Pod 容器终端, -c container-name 可以指定进入哪个容器。
10sudo kubectl exec -it <pod-name> -- bash

Node

 1# 查看节点
 2sudo kubectl get nodes
 3# 为指定节点添加标签
 4sudo kubectl label nodes <node-name> disktype=ssd
 5# 为指定节点删除标签
 6sudo kubectl label nodes <node-name> <label-name>-
 7# 查看节点标签
 8sudo kubectl get nodes --show-labels
 9# 查看节点资源占用 (当前 CPU、Memory 占用情况)
10sudo kubectl top nodes

Misc

 1# 重启指定资源
 2kubectl rollout restart <resource-type> <resource-name>
 3# 查看服务
 4sudo kubectl get svc
 5# 将指定 Pod 的指定端口映射到节点(对外暴露端口)
 6# 使用资源类型/名称(例如 deployment/mydeployment)来选择一个 pod。
 7# 如果省略,资源类型默认为 "pod"。
 8sudo kubectl port-forward <pod-name> 8090:8080
 9# 查看全部
10sudo kubectl get all
11# 删除全部资源
12sudo kubectl delete all --all
13# 查看 ConfigMap
14sudo kubectl get configmap <config-map-name> -o yaml
15# 查看 Secret
16sudo kubectl get secret <secret-name> -o yaml
17# 查看 PV(卷)
18sudo kubectl get pv
19# 删除 PV(卷)
20sudo kubectl delete pv <pv-name>
21# 查看 PVC(持久卷)
22sudo kubectl get pvc
23# 查看 StorageClass
24sudo kubectl get storageclass
25# 删除 StorageClass
26sudo kubectl delete storageclass <storage-class-name>
27# 查看服务关联的端点
28sudo kubectl get endpoints <service-name>
29# 查看特定资源或资源组的详细信息
30# kubectl describe TYPE NAME_PREFIX
31sudo kubectl describe pod <pod-name>

常用示例

将 Pod 调度到指定节点

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: nginx
 5spec:
 6  nodeName: foo-node # 调度 Pod 到指定的节点
 7  containers:
 8  - name: nginx
 9    image: nginx
10    imagePullPolicy: IfNotPresent

使用此配置文件来创建一个 Pod,该 Pod 将只能被调度到 foo-node 节点。

将 Pod 调度到含指定标签的节点

节点信息:

1NAME      STATUS    AGE     VERSION            LABELS
2worker0   Ready     1d      v1.6.0+fff5156     ...,disktype=ssd,kubernetes.io/hostname=worker0
3worker1   Ready     1d      v1.6.0+fff5156     ...,kubernetes.io/hostname=worker1
4worker2   Ready     1d      v1.6.0+fff5156     ...,kubernetes.io/hostname=worker2

Pod 配置文件:

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: nginx
 5  labels:
 6    env: test
 7spec:
 8  containers:
 9  - name: nginx
10    image: nginx
11    imagePullPolicy: IfNotPresent
12  nodeSelector:
13    disktype: ssd

该 Pod 将被调度到有 disktype=ssd 标签的节点,即 worker0 节点。

  • nodeSelector 与 nodeAffinity 都可用于指定绑定到具体 node。如果同时指定 nodeSelector 和 nodeAffinity,两者必须都要满足,才能将 Pod 调度到候选节点。
  • 如果在与 nodeAffinity 类型关联的 nodeSelectorTerms 中指定多个条件,只要其中一个 nodeSelectorTerms 满足(各个条件按逻辑或操作组合)的话,Pod 就可以被调度到节点上。
  • 如果在与 nodeSelectorTerms 中的条件相关联的单个 matchExpressions 字段中指定多个表达式,则只有当所有表达式都满足(各表达式按逻辑与操作组合),Pod 才能被调度到节点上。

参阅使用节点亲和性来为 Pod 指派节点, 以了解进一步的信息。

节点退出(剔除)

在硬件升级、维护或节点出现异常等情况下,需要将某些剔除,使其脱离 kubernetes 集群的调度范围。

  1. 将要剔除的节点设置成不可调度状态
kubectl cordon test-k8s-node05

设置之后节点状态会多一个 SchedulingDisabled 标记,之后新创建的 Pod 将不会往该节点调度。

  1. 驱逐调节点上的pod
kubectl drain test-k8s-node05

如果是节点出了问题,执行不了指令,可以采取强制驱逐的方式

kubectl delete pods -n kube-system nginx-6qz6s
  1. 将节点从集群中剔除
kubectl delete node test-k8s-node05

Kind 特性

Pod

  • 需要端口转发才能访问
  • 每次重新创建,IP 和 Name 都会变更

服务 (Service)

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。使用 Kubernetes,你无需修改应用程序去使用不熟悉的服务发现机制。Kubernetes 为 Pod 提供自己的 IP 地址,并为一组 Pod 提供相同的 DNS 名,并且可以在它们之间进行负载均衡。

  • 通过 label 跟 Pod 进行关联
  • 生命周期不跟 Pod 绑定,不会因为 Pod 重创改变 IP
  • 提供了负载均衡功能,自动转发流量到不同 Pod
  • 可实现对集群外部提供访问端口
  • 集群内部(同一命名空间)可通过服务名称访问 (带负载均衡)

TODO: 可通过 pod-name.service-name 连接指定 Pod。

StatefulSet

  • Pod 名字也是固定的。
  • Pod 创建和销毁是有序的,创建是顺序的,销毁是逆序的。
  • Pod 重建不会改变名字 (IP 依然会变)

数据持久化

容器(Container) 中的文件在主机磁盘上是临时的,这带来了一些问题。问题之一是当容器崩溃时文件会丢失,因为 kubelet 会以干净的状态重启容器。第二个问题是同一 Pod 中运行多个容器并共享文件时出现的竞争。Kubernetes 卷 (Volume) 这一抽象概念能够解决这两个问题。

Kubernetes 支持很多类型的卷。Pod 可以同时使用任意数目的卷类型。临时卷(Ephemeral Volume) 类型的生命周期与 Pod 相同,持久卷 (Persistent Volume) 可以比 Pod 的存活期长。当 Pod 不再存在时,Kubernetes 仅销毁临时卷,不销毁持久卷。对于给定 Pod 中任何类型的卷,在容器重启期间数据都不会丢失。

PV 卷是集群中的资源。PVC 申领是对这些资源的请求,也被用来执行对资源的申领检查。

**卷的核心是一个目录,其中可能存有数据,Pod 中的容器可以访问该目录中的数据。**所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的内容。

TODO: 除临时卷和持久卷外,还有 投射卷 (Projected Volumes)

整体流程

  1. Persistent Volume Claim (PVC) (持久卷申领)

persistentVolumeClaim 卷用来将持久卷(PersistentVolume)挂载到 Pod 中。持久卷申领(PersistentVolumeClaim)是用户在不知道特定云环境细节的情况下“申领”持久存储(例如 GCE PersistentDisk 或者 iSCSI 卷)的一种方法。

持久卷申领(PersistentVolumeClaim,PVC)表达的是用户对存储的请求,概念上与 Pod 类似。Pod 会耗用节点资源,而 PVC 申领会耗用 PV 资源。

Pod 可以请求特定数量的资源(CPU 和内存),同样 PVC 申领可以请求特定的大小和访问模式的 PV

例如,可以要求能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载的 PV,Kubernetes 控制平面将查找满足申领要求的 PersistentVolume。如果控制平面找到具有相同 StorageClass 的适当的 PersistentVolume,则将 PersistentVolumeClaim 绑定到该 PersistentVolume 上。

  • 默认情况下,申请容量为小于等于 10Gi 的 PVC,可以和 10Gi 的 PV 绑定。
  • 未指定 PV 名称或选择器的 PVC 将与任何 PV 匹配。要将 PVC 绑定到特定 PV, 在知道 PV 名称时,可使用 pvc.spec.volumeName 指定, 在知道 PV 标签(Label)时,可请使用 pvc.spec.selector 指定。
 1apiVersion: v1
 2kind: PersistentVolumeClaim
 3metadata:
 4  name: mongodata
 5spec:
 6  accessModes: ["ReadWriteOnce"]
 7  storageClassName: "local-storage"
 8  resources:
 9    requests:
10      storage: 2Gi
11  # volumeName: <pv-name>  # 通过 PV 卷名称指定要申领的 PV
12  # nodeSelector:  # TODO: 隐约记得这玩意儿好像是 Pod 的配置项?
13  #   accelerator: nvidia-tesla-p100  # 匹配标签,与名称和 UID 不同,标签不提供唯一性。通常,我们希望许多对象带有相同的标签。
14  # selector:  # TODO: 这种类型的选择器在 PVC 中好像不受支持?
15  #   target: monitor
16  selector:
17    matchLabels:
18      target: redis
19  #   matchExpressions:
20  #     - {key: tier, operator: In, values: [cache]}
21  #     - {key: environment, operator: NotIn, values: [dev]}
  1. Persistent Volume (PV) (持久卷)

持久卷(PersistentVolume,PV) 是集群中的一块存储,可以由管理员事先制备,或者使用存储类(Storage Class)来动态制备。持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样, 也是使用卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。

关于访问模式(accessModes):

  • ReadWriteOnce:卷可以被一个节点以读写方式挂载。需要注意的是,这意味着其允许运行在同一节点上的多个 Pod 访问卷。
  • ReadOnlyMany:卷可以被多个节点以只读方式挂载。
  • ReadWriteMany:卷可以被多个节点以读写方式挂载。
  • ReadWriteOncePod:卷可以被单个 Pod 以读写方式挂载。如果你想确保整个集群中只有一个 Pod 可以读取或写入该 PVC,请使用 ReadWriteOncePod 访问模式。这只支持 CSI 卷并且需要 Kubernetes 1.22 以上版本。
  • PV 可以通过设置节点亲和性来定义一些约束,进而限制可以从哪些节点上访问此 PV。**使用这些卷的 Pod 只会被调度到节点亲和性规则所选择的节点上执行。**大多数类型的 PV 都不需要设置节点亲和性字段。AWSEBS、GCE PD 和 Azure Disk 卷类型都能自动设置相关字段。通常只有 local 卷需要显式地设置此属性。
  • 将 PV 的 claimRef 字段设为相关的 PersistentVolumeClaim,可以确保其他 PVC 不会绑定到该 PV 卷。
  • 每个 PV 同一时刻只能以一种访问模式挂载,即使该卷支持多种访问模式。
 1apiVersion: v1
 2kind: PersistentVolume
 3metadata:
 4  name: mongodata
 5spec:
 6  capacity:
 7    storage: 2Gi
 8  volumeMode: Filesystem  # Filesystem(文件系统) Block(块)
 9  accessModes:
10    - ReadWriteOnce       # 卷可以被一个节点以读写方式挂载
11  persistentVolumeReclaimPolicy: Delete
12  storageClassName: local-storage
13  local:
14    path: /root/data
15  nodeAffinity:
16    required:
17      # 通过 hostname 限定在某个节点创建存储卷
18      nodeSelectorTerms:
19        - matchExpressions:
20            - key: kubernetes.io/hostname
21              operator: In
22              values:
23                - node2
  1. Storage Class (SC) (存储类)

尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源,常见的情况是针对不同的问题用户需要的是具有不同属性(如,性能)的 PersistentVolume 卷。集群管理员需要能够提供不同性质的 PersistentVolume,并且这些 PV 卷之间的差别不仅限于卷大小和访问模式,同时又不能将卷是如何实现的这些细节暴露给用户。为了满足这类需求,就有了存储类(StorageClass) 资源。

每个 StorageClass 都包含 provisionerparametersreclaimPolicy 字段,这些字段会在 StorageClass 需要动态制备 PersistentVolume 时会使用到。

1apiVersion: storage.k8s.io/v1
2kind: StorageClass
3metadata:
4  name: slow
5provisioner: kubernetes.io/aws-ebs
6parameters:
7  type: io1
8  iopsPerGB: "10"
9  fsType: ext4

完整示例 (本地磁盘)

使用此示例时,请提前创建 /root/data 目录,否则试图挂载该 PV 的 Pod 将卡在 ContainerCreating 状态下无法正常启动。

 1apiVersion: apps/v1
 2kind: StatefulSet
 3metadata:
 4  name: mongodb
 5spec:
 6  replicas: 1
 7  selector:
 8    matchLabels:
 9      app: mongodb
10  template:
11    metadata:
12      labels:
13        app: mongodb
14    spec:
15      containers:
16        image: mongo:5.0
17        imagePullPolicy: IfNotPresent
18        name: mongo
19        volumeMounts:
20          - mountPath: /data/db
21            name: mongo-data
22      volumes:
23        - name: mongo-data
24          persistentVolumeClaim:
25             claimName: mongodata
26---
27apiVersion: v1
28kind: Service
29metadata:
30  name: mongodb
31spec:
32  clusterIP: None
33  ports:
34  - port: 27017
35    protocol: TCP
36    targetPort: 27017
37  selector:
38    app: mongodb
39  type: ClusterIP
40---
41apiVersion: storage.k8s.io/v1
42kind: StorageClass
43metadata:
44  name: local-storage
45provisioner: kubernetes.io/no-provisioner
46volumeBindingMode: WaitForFirstConsumer
47---
48apiVersion: v1
49kind: PersistentVolume
50metadata:
51  name: mongodata
52spec:
53  capacity:
54    storage: 2Gi
55  volumeMode: Filesystem  # Filesystem(文件系统) Block(块)
56  accessModes:
57    - ReadWriteOnce       # 卷可以被一个节点以读写方式挂载
58  persistentVolumeReclaimPolicy: Delete
59  storageClassName: local-storage
60  local:
61    path: /root/data
62  nodeAffinity:
63    required:
64      # 通过 hostname 限定在某个节点创建存储卷
65      nodeSelectorTerms:
66        - matchExpressions:
67            - key: kubernetes.io/hostname
68              operator: In
69              values:
70                - node2
71---
72apiVersion: v1
73kind: PersistentVolumeClaim
74metadata:
75  name: mongodata
76spec:
77  accessModes: ["ReadWriteOnce"]
78  storageClassName: "local-storage"
79  resources:
80    requests:
81      storage: 2Gi

ConfigMap & Secret

ConfigMap

用于配置一些变量,例如数据库连接地址等根据部署环境变化的,不能写死的信息。

1# configmap.yaml
2apiVersion: v1
3kind: ConfigMap
4metadata:
5  name: <config-map-name>
6data:
7  mongoHost: mongodb-0.mongodb
1# 应用
2sudo kubectl apply -f configmap.yaml
3# 查看
4sudo kubectl get configmap <config-map-name> -o yaml

Secret

用于保存一些重要数据,例如密码、TOKEN。文档,配置证书

 1# secret.yaml
 2apiVersion: v1
 3kind: Secret
 4metadata:
 5  name: <secret-name>
 6# Opaque 用户定义的任意数据
 7# 更多类型: https://kubernetes.io/zh/docs/concepts/configuration/secret/#secret-types
 8type: Opaque
 9data:
10  # 数据需要进行 Base64 编码
11  mongo-username: bW9uZ291c2Vy
# 应用
sudo kubectl apply -f secret.yaml
# 查看
sudo kubectl get secret <secret-name> -o yaml

使用方法

作为环境变量:

 1apiVersion: apps/v1
 2kind: StatefulSet
 3metadata:
 4  name: mongodb
 5spec:
 6  replicas: 3
 7  selector:
 8    matchLabels:
 9      app: mongodb
10  template:
11    metadata:
12      labels:
13        app: mongodb
14    spec:
15      containers:
16        - name: mongo
17          image: mongo:4.4
18          env:
19          - name: MONGO_INITDB_ROOT_USERNAME
20            valueFrom:
21              secretKeyRef:
22                name: mongo-secret
23                key: mongo-username

挂载为文件:

 1apiVersion: v1
 2kind: Pod
 3metadata:
 4  name: mypod
 5spec:
 6  containers:
 7  - name: mypod
 8    image: redis
 9    volumeMounts:
10    - name: foo
11      mountPath: "/etc/foo"
12      readOnly: true
13  # 挂载后会在容器中对应路径生成一个 key 文件,内容就是 value
14  volumes:
15  - name: foo
16    secret:
17      secretName: mysecret

命名空间

如果一个集群中部署了多个应用,所有应用都在一起,就不太好管理,也可以导致名字冲突等。 此时可以使用 namespace 把应用划分到不同的命名空间,跟代码里的 namespace 是一个概念。

1# 创建命名空间
2sudo kubectl create namespace testapp
3# 部署应用到指定的命名空间
4sudo kubectl apply -f app.yml --namespace testapp
5# 查询指定命名空间中的 Pod
6sudo kubectl get pod --namespace kube-system

使用 kubens 快速切换 namespace

1# 切换命名空间
2kubens kube-system
3# 回到上个命名空间
4kubens -
5# 切换集群
6kubectx minikube

Ingress

Ingress 作为 Kubernetes 集群内服务对外暴露的访问接入点,其几乎承载着集群内服务访问的所有流量。Ingress 是 Kubernetes 中的一个资源对象,用来管理集群外部访问集群内部服务的方式。

可以通过 Ingress 资源来配置不同的转发(路由)规则,从而达到根据不同的规则设置访问集群内不同的 Service 所对应的后端 Pod。

Ingress 资源仅支持配置 HTTP 流量转发规则,无法配置一些高级特性,负载均衡的算法、Sessions Affinity 等高级特性都需要在 Ingress Controller 中进行配置。

简而言之,其功能类似 Nginx Proxy,可以根据域名、路径把请求转发到不同的 Service(负载均衡),也可配置 https。

Ingress

以下是一个 Ingress 的最小示例(Nginx controller):

 1apiVersion: networking.k8s.io/v1
 2kind: Ingress
 3
 4metadata:
 5  name: minimal-ingress
 6  annotations:
 7    nginx.ingress.kubernetes.io/rewrite-target: /
 8
 9spec:
10  ingressClassName: nginx-example
11  rules:
12  - http:
13      paths:
14      - path: /testpath
15        pathType: Prefix
16        backend:
17          service:
18            name: test
19            port:
20              number: 80

Ingress 控制器(Controller)与 Ingress 资源

为了使得 Ingress 资源正常工作,集群中必须要有一个 Ingress Controller 来解析 Ingress 的转发规则。Ingress Controller 收到请求,匹配 Ingress 转发规则转发到后端 Service 所对应的 Pod,由 Pod 处理请求。

Ingress 是反向代理规则,用来规定 HTTP/HTTPS 请求应该被转发到哪个 Service 所对应的 Pod 上。例如根据请求中不同的 Host 和 URL 路径,让请求落到不同 Service 所对应的 Pod 上。

Ingress Controller 是一个反向代理程序,负责解析 Ingress 的反向代理规则。如果 Ingress 有增删改等变动,Ingress Controller 会及时更新自己相应的转发规则,当 Ingress Controller 收到请求后就会根据这些规则将请求转发到对应 Service 的 Pod 上。

Ingress Controller 通过 API Server 获取 Ingress 资源的变化,动态地生成 Load Balancer(例如Nginx)所需的配置文件(例如 nginx.conf),然后重新加载 Load Balancer(例如执行 nginx -s load重新加载Nginx)来生成新的路由转发规则。

Ingress Controller 通过配置 LoadBalancer 类型的 Service 来创建 SLB,因此可以从外部通过 SLB 访问到 Kubernetes 集群的内部服务。根据 Ingress 配置的不同规则来访问不同的服务。

  • Ingress 控制器通常通过负载均衡器(LB)实现 Ingress,另外也可以通过配置边缘路由器(Edge Router)或其他前端实现 Ingress。

Ingress Rules

每个 Ingress HTTP 规则都包含以下信息:

  • host(可选):在上述示例中,未指定 host,因此该规则适用于通过指定 IP 地址的所有入站 HTTP 通信。如果提供了 host(例如 foo.bar.com),则 rules 适用于该 host。
  • paths:即路径列表,每个路径都有一个由 service.nameservice.port.nameservice.port.number 定义的关联后端。当前支持的路径类型有三种:
    • ImplementationSpecific:这种路径类型匹配方法取决于 IngressClass,具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理。
    • Exact:精确匹配 URL 路径,且区分大小写。
    • Prefix:基于以 / 分隔的 URL 路径前缀匹配,区分大小写,会对路径元素逐个进行匹配。
  • backend,即后端,是 Service 文档中所述的服务和端口名称的组合,或者是通过 CRD 方式来实现的自定义资源后端。与规则的 host 和 path 匹配的对 Ingress 的 HTTP(S) 请求将发送到列出的 backend。

Ingress Class

IngressClass 是 Ingress 处理器的描述,用于在 K8s 集群中声明一个 Ingress 处理器实现,关联该 IngressClass 的 Ingress 资源会被该 Ingress 处理器解析。

 1apiVersion: networking.k8s.io/v1
 2kind: IngressClass
 3metadata:
 4  name: external-lb
 5spec:
 6  controller: example.com/ingress-controller
 7  parameters:
 8    apiGroup: k8s.example.com
 9    kind: IngressParameters
10    name: external-lb
  • IngressClass 中的 .spec.parameters 字段可用于引用其他资源以提供额外的相关配置,具体类型取决于 .spec.controller 字段中指定的 Ingress 控制器。

TLS Config

 1apiVersion: v1
 2kind: Secret
 3metadata:
 4  name: testsecret-tls
 5  namespace: default
 6data:
 7  tls.crt: base64 编码的证书
 8  tls.key: base64 编码的私钥
 9type: kubernetes.io/tls
10
11---
12
13apiVersion: networking.k8s.io/v1
14kind: Ingress
15metadata:
16  name: tls-example-ingress
17spec:
18  tls:
19  - hosts:
20      - https-example.foo.com
21    secretName: testsecret-tls
22  rules:
23  - host: https-example.foo.com
24    http:
25      paths:
26      - path: /
27        pathType: Prefix
28        backend:
29          service:
30            name: service1
31            port:
32              number: 80

Resource backend

Resource 后端是一个引用,指向同一命名空间中的另一个 Kubernetes 资源,将其作为 Ingress 对象。Resource 后端与 Service 后端是互斥的,在二者均被设置时会无法通过合法性检查。Resource 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端

 1apiVersion: networking.k8s.io/v1
 2kind: Ingress
 3metadata:
 4  name: ingress-resource-backend
 5spec:
 6  defaultBackend:
 7    resource:
 8      apiGroup: k8s.example.com
 9      kind: StorageBucket
10      name: static-assets
11  rules:
12    - http:
13        paths:
14          - path: /icons
15            pathType: ImplementationSpecific
16            backend:
17              resource:
18                apiGroup: k8s.example.com
19                kind: StorageBucket
20                name: icon-assets

小结

  • 必须拥有一个 Ingress 控制器才能满足 Ingress 的要求,仅创建 Ingress 资源本身没有任何效果
  • Ingress 对象的命名必须是合法的 DNS 子域名名称。
  • Ingress 经常使用注解(annotations)来配置一些选项,不同的 Ingress 控制器配置选项也不尽相同。
  • 省略 ingressClassName 时,应该定义一个默认 Ingress 类。部分 Ingress 控制器不需要定义默认 IngressClass。比如 Ingress-NGINX 控制器可以通过参数 –watch-ingress-without-class 来配置。
  • 没有设置规则的 Ingress 将所有流量发送到同一个默认后端(.spec.defaultBackend)。
  • host 可以是精确匹配或者使用通配符匹配。

Endpoint

endpoint 是 k8s 集群中的一个资源对象,存储在 etcd 中,用来记录一个 service 对应的所有 pod 的访问地址。

service 通过 selector 和 pod 建立关联。k8s 会根据 service 关联到 pod 的 podIP 信息组合成一个 endpoint。

Endpoint Controller

endpoints controller 是 kube-controller-manager 组件中众多控制器中的一个,是 endpoints 资源对象的控制器,其通过监听 service 和 pod 2种资源的变化触发 endpoints controller 对相应的 endpoints 资源进行调谐操作,从而完成 endpoints 对象的新建、更新、删除等操作。

简而言之,endpoint controller 负载维护 endpoint 资源对象,主要的功能有下面几种:

  • 生成和维护所有 endpoint 对象的控制器;
  • 监听 service 和对应 pod 的变化;
  • service 被删除,则删除和该 service 同名的 endpoint 对象;
  • service 被创建,则根据新建 service 信息获取相关 pod 列表,然后创建对应 endpoint 对象;
  • service 被更新,则根据更新后的 service 信息获取相关 pod 列表,然后更新对应 endpoint 对象;
  • pod 更新,则更新对应的 service 的 endpoint 对象,将 pod IP 记录到 endpoint 中;

如果 service 没有 selector 字段,其被创建的时候,endpoint controller 不会自动创建 endpoint。

Kube Proxy

kube-proxy 是 Kubernetes 的核心组件,其存在于每个 node 节点上,是实现 Service 与 Pod 之间通信及负载均衡的重要组件。kube-proxy 会为 Pod 创建代理服务,也会从 apiserver 获取所有 server 信息,并根据 server 信息创建相应代理服务,实现 server 到 Pod 的请求的路由和转发,从而实现 K8s 层级的虚拟转发网络。

对于外部访问 service 的请求,不论是 Cluster IP + Target Port 还是 Node 节点 IP + NodePort 的方式,都会被 Node 节点的 Iptables 规则重定向到 Kube-proxy 监听 Service 服务代理端口。kube-proxy 接收到 Service 的访问请求后,根据负载策略,转发到后端的 Pod。

kube-proxy 的路由转发规则是通过其后端的代理模块实现的,其中 kube-proxy 的代理模块目前有四种实现方案,userspace、iptables、ipvs(默认)、kernelspace。

在 k8s 中提供相同服务的一组 pod 可以抽象成一个 service,通过 service 提供统一的服务对外提供服务。

番外

Metrics

Metrics 用于收集资源指标,kubectl topHap 等功能对 Metrics 有依赖。

Hap 的自动扩容与缩容正是以 Metrics 为根基实现的。

无头服务(Headless Services)

有时不需要或不想要负载均衡,以及单独的 Service IP。 遇到这种情况,可以通过指定 Cluster IP(spec.clusterIP)的值为 “None” 来创建 Headless Service。

你可以使用一个无头 Service 与其他服务发现机制进行接口,而不必与 Kubernetes 的实现捆绑在一起。

对于无头 Services 并不会分配 Cluster IP,kube-proxy 不会处理它们, 而且平台也不会为它们进行负载均衡和路由。DNS 如何实现自动配置,依赖于 Service 是否定义了选择算符。

Helm

Helm 类似 DockerHub, 可以理解为是一个软件库,可以方便快速的为我们的集群安装一些第三方软件。

PersistentVolume 回收策略

PersistentVolumes 可以有多种回收策略,包括 Retain (保留)Recycle (回收)Delete (删除)。对于动态配置的 PersistentVolumes 来说,默认回收策略为 “Delete”

  • Delete: 用户删除对应的 PersistentVolumeClaim 时,如果下层的卷插件支持,删除动作会将 PersistentVolume 对象从 Kubernetes 中移除,同时也会从外部基础设施(如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)中移除所关联的存储资产。
  • Retain: 当 PersistentVolumeClaim 对象被删除时,PersistentVolume 卷仍然存在,对应的数据卷被视为Released (已释放)。由于卷上仍然存在前一申领人的数据,该卷在由管理员手动回收前不能用于其他申领。
  • Recycle: 用户删除 PersistentVolumeClaim 时,如果下层的卷插件支持,会在卷上执行一些基本的擦除 (rm -rf /thevolume/*)操作后允许该卷用于新的 PVC 申领。

Retain 回收政策下手动回收该卷的步骤:

  1. 手动删除 PersistentVolume 对象 (与之相关的、位于外部基础设施中的存储资产(例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)在 PV 删除之后仍然存在)
  2. 视情况手动清除所关联存储资产上的数据。
  3. 手动删除所关联的存储资产。

警告: 回收策略 Recycle 已被废弃。取而代之的建议方案是使用动态制备。

动态制备的卷会继承其 StorageClass 中设置的回收策略,该策略默认为 Delete。

PersistentVolume 绑定模式

volumeBindingMode 字段控制了卷绑定和动态制备应该发生在什么时候。

Immediate 模式默认情况下表示,一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。

WaitForFirstConsumer 模式下,将延迟 PersistentVolume 的绑定和制备,直到使用该 PersistentVolumeClaim 的 Pod 被创建。

Pod 重启策略

Pod 通过 restartPolicy 字段指定重启策略,重启策略类型为:Always、OnFailure 和Never,默认为Always。

Pod 内部容器互联

按照 Kubernetes 的工作方式,同一 Pod 中的所有容器都在同一个网络命名空间上,这意味着它们可以通过 localhost 相互通信。

各类 IP 用途

Kubernetes 集群内部存在三类 IP,分别是:

  • Node IP: 节点主机 IP 地址
  • Pod IP: 使用 CNI (网络插件) 创建的 IP (如 flannel)
  • Cluster IP: 虚拟 IP,通过 iptables 规则访问服务

Pod IP 用于让跨主机 Pod 之间的互通。

Init 容器

Pod 能够具有多个容器,应用运行在容器里面,但是也可能有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像,以下简单列举几点不同之处:

  • 总是运行到成功完成为止(即 exit code 为 0)。
  • 每个都必须在下一个启动之前成功完成。。
  • 同一部署中的 Init 容器全部完成以后,才会开始启动应用容器。

如果 Pod 的 Init 容器失败,kubelet 会不断地重启该 Init 容器直到该容器成功为止。然而,如果 Pod 对应的 restartPolicy 值为 “Never”,并且 Pod 的 Init 容器失败, 则 Kubernetes 会将整个 Pod 状态设置为失败。

Flannel

Flannel 配置第 3 层 IPv4 overlay 网络。它会创建一个大型内部网络,跨越集群中每个节点。在此 overlay 网络中,每个节点都有一个子网,用于在内部分配 IP 地址。在配置 Pod 时,每个节点上的 Docker (也可能是其他的) 桥接口都会为每个新容器分配一个地址。同一主机中的 Pod 可以使用 Docker (也可能是其他的) 桥接进行通信,不同主机上的 Pod 则会使用 flanneld 将其流量封装在 UDP 数据包中,以便路由到适当的目标。

概况一下,Flannel 可能是目前最简单和最受欢迎的 CNI 插件。其作为一个二进制文件部署在每个 Node 上,主要实现作用如下:

  • 为 Node 分配 subnet,node 中的容器将自动从该子网中获取 IP 地址
  • 新 Node 加入网络时,为所有 node 增加(更新)相应路由配置
  • 让不同 Node 中 Pod 的能够互相通信

CNI

CNI 意为容器网络接口,它是一种标准的设计,为了让用户在容器创建或销毁时都能够更容易地配置容器网络。

CNI 的初衷是创建一个框架,用于在配置或销毁容器时动态配置适当的网络配置和资源CNI 规范 概括了用于配制网络的插件接口,该接口让容器运行时能够与插件进行协调。

插件负责为接口配置和管理 IP 地址,并且通常提供与 IP 管理、每个容器的 IP 分配、以及多主机连接相关的功能。容器运行时会调用网络插件,从而在容器启动时分配 IP 地址并配置网络,并在删除容器时再次调用它以清理这些资源。

运行时或协调器决定了容器应该加入哪个网络以及它需要调用哪个插件。然后,插件会将接口添加到容器网络命名空间中,作为一个 veth 对的一侧。接着,它会在主机上进行更改,包括将 veth 的其他部分连接到网桥。再之后,它会通过调用单独的 IPAM(IP 地址管理)插件来分配 IP 地址并设置路由。

在 Kubernetes 中,kubelet 可以在适当的时间调用它找到的插件,来为通过 kubelet 启动的 pod 进行自动的网络配置。

容器网络是容器选择连接到其他容器、主机和外部网络(如 Internet)的机制。容器的 runtime 提供了各种网络模式,每种模式都会产生不同的体验。

术语

  • 第 2 层网络 : OSI(Open Systems Interconnections,开放系统互连)网络模型的“数据链路”层。第 2 层网络会处理网络上两个相邻节点之间的帧传递。第 2 层网络的一个值得注意的示例是以太网,其中 MAC 表示为子层。
  • 第 3 层网络 : OSI 网络模型的“网络”层。第 3 层网络的主要关注点,是在第 2 层连接之上的主机之间路由数据包。IPv4、IPv6 和 ICMP 是第 3 层网络协议的示例。
  • VXLAN :代表“虚拟可扩展 LAN”。首先,VXLAN 用于通过在 UDP 数据报中封装第 2 层以太网帧来帮助实现大型云部署。VXLAN 虚拟化与 VLAN 类似,但提供更大的灵活性和功能(VLAN 仅限于 4096 个网络 ID)。VXLAN 是一种封装和覆盖协议,可在现有网络上运行。
  • Overlay 网络 :Overlay 网络是建立在现有网络之上的虚拟逻辑网络。Overlay 网络通常用于在现有网络之上提供有用的抽象,并分离和保护不同的逻辑网络。
  • 封装 :封装是指在附加层中封装网络数据包以提供其他上下文和信息的过程。在 overlay 网络中,封装被用于从虚拟网络转换到底层地址空间,从而能路由到不同的位置(数据包可以被解封装,并继续到其目的地)。
  • 网状网络 :网状网络(Mesh network)是指每个节点连接到许多其他节点以协作路由、并实现更大连接的网络。网状网络允许通过多个路径进行路由,从而提供更可靠的网络。网状网格的缺点是每个附加节点都会增加大量开销。
  • BGP :代表“边界网关协议”,用于管理边缘路由器之间数据包的路由方式。BGP 通过考虑可用路径,路由规则和特定网络策略,帮助弄清楚如何将数据包从一个网络发送到另一个网络。BGP 有时被用作 CNI 插件中的路由机制,而不是封装的覆盖网络。

Metrics Server

metrics-server 通过 kubelet(cAdvisor)获取监控数据,主要作用是为 kube-scheduler、HPA 等 K8s 核心组件及 kubectl top 命令和 Dashboard 等 UI 组件提供数据。

各类 Port 对应关系

 1apiVersion: extensions/v1beta1
 2kind: Deployment
 3metadata:
 4  name: tomcat-deployment
 5spec:
 6  replicas: 3
 7  template:
 8    metadata:
 9      labels:
10        app: tomcat
11        tier: frontend
12    spec:
13      containers:
14        - name: tomcat
15          image: docker.cinyi.com:443/tomcat
16          ports:
17          - containerPort: 80   # 容器内部 Port
 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: tomcat-server
 5spec:
 6  type: NodePort
 7  selector:
 8    tier: frontend
 9  ports:
10      # Service 暴露在 ClusterIP 上的端口,通过 <cluster ip>:<port> 访问服务, 通过此端口集群内的服务可以相互访问
11      port: 11111
12      # # 指定 Pod 的外部访问端口,port 和 nodePort 的数据通过此端口进入到 Pod, 应与 Deployment 中想绑定的 `containerPort` 一致
13      # 默认情况下,`targetPort` 被设为与 `port` 字段相同的值。
14      targetPort: 8080
15      # Node节点的端口,<nodeIP>:nodePort 是提供给集群外部客户访问service的入口
16      nodePort: 30001

疑问

  • Pod 总是与 PV 在同一节点?

设置节点亲和性约束后,才会将 Pod 调度到 PV 所在节点。而对于节点亲和性约束,通常只对 Local 类型的 PV 进行设置。

  • Nginx 反向代理中直接填写服务名称为什么无法解析到相应服务?

通常,直接使用服务名字即可通过 DNS 解析后连接到相应服务,不需要使用 IP 地址。Nginx 由于不支持 DNS Search,所以需要填写完整的地址,即 <server-name>.<namespace>.svc.cluster.local

  • 如何设置镜像加速?

编辑 /etc/rancher/k3s/registries.yaml 文件添加如下配置:

1mirrors:
2  "docker.io":
3    endpoint:
4      - "https://ovfftd6p.mirror.aliyuncs.com"
5      - "https://docker.mirrors.ustc.edu.cn"
6      - "https://hub-mirror.c.163.com"

然后重启服务 sudo systemctl restart k3s,使用 sudo crictl info | grep -A 5 "endpoint" 查看是否有返回刚才设在的那些地址,有则已生效。

  • 有类似 Docker Compose 中 depends_on 的东西吗?

没事的,但是可以通过 initContainer 实现类似的效果。

以下示例配置中,Nginx 将等待 Mariadb 启动完成后再启动。

 1apiVersion: apps/v1
 2kind: Deployment
 3
 4metadata:
 5  name: db
 6
 7spec:
 8  replicas: 1
 9  selector:
10    matchLabels:
11      app: db
12  template:
13    metadata:
14      labels:
15        app: db
16    spec:
17      containers:
18      - name: mariadb
19        image: mariadb:10.10
20
21---
22
23apiVersion: v1
24kind: Service
25
26metadata:
27  name: db
28
29spec:
30  ports:
31    - port: 33306
32      targetPort: 3306
33  selector:
34    app: db
35
36---
37
38apiVersion: apps/v1
39kind: Deployment
40
41metadata:
42  name: nginx
43
44spec:
45  replicas: 1
46  selector:
47    matchLabels:
48      app: nginx
49  template:
50    metadata:
51      labels:
52        app: nginx
53    spec:
54      initContainers:
55      - name: init-cont
56        image: busybox:1.31
57        command: ['sh', '-c', 'until nslookup db; do echo waiting for mysql; sleep 2; done;']
58      containers:
59      - name: nginx
60        image: nginx:latest

参考资料