引言
这篇重点介绍K8s的资源组件和相关配置使用。
1. Node & Pod
Node:
是 Pod 真正运行的主机,可以是物理机,也可以是虚拟机。为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 docker, rkt, containerd)、kubelet 和 kube-proxy 服务。
Pod:
是一组紧密关联的容器集合(也可以是单个容器),它们共享 IPC(进程间通信) , Network namespace 和 文件存储(需挂载到容器),是 Kubernetes 调度的基本单位。
Node和Pod的关系如下图所示:

上图中的Node中共有4个Pod,分别为:

2. Namespaces
是对一组资源和对象的抽象集合,相当于给k8s系统内部的对象划分一些命名空间。常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的(默认是 default)。
创建命名空间的配置示例:
1 2 3 4
| apiVersion: v1 kind: Namespace metadata: name: test
|
命名空间的使用则是通过Pod或Service中的metadata.namespace字段来声明。
3. Service
是应用服务的抽象,为应用提供负载均衡和服务发现。它通过将多个 Pod IP 和端口列表组成 endpoints,由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
每个 Service 都会自动分配一个 cluster IP(仅在集群内部可访问的虚拟地址)和 DNS 名,其他容器可以通过该地址或 DNS 来访问服务,而不需要了解后端容器的运行。
Service模型如下所示:

创建Service的配置:
1 2 3 4 5 6 7 8 9 10 11 12 13
| kind: Service apiVersion: v1 metadata: name: {{name}} namespace: {{namespace}} spec: selector: k8s-app: {{name}} ports: - name: serviceport protocol: TCP port: 8081 targetPort: 8081
|
4. Ingress
为进入集群的请求提供路由规则的集合,类似于反向代理Nginx的作用,它可以按规则将请求路由到具体的Service上。
Ingress模型如下图示例:

创建Ingress的配置规则:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
| apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80 - host: bar.foo.com http: paths: - backend: serviceName: s2 servicePort: 80
|
5. Deployment
用于无状态 Pod 部署声明,这些Pod对部署顺序没有要求(如nginx),可以定义 Pod 的副本数量,调度策略等,是最常用的一种部署方式,一般将 Pod 的定义内置在 Deployment 中。
Deployment的配置规则示例:
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
| apiVersion: apps/v1 kind: Deployment metadata: name: {{name}} namespace: {{namespace}} spec: replicas: 2 selector: matchLabels: k8s-app: {{name}} template: metadata: labels: k8s-app: {{name}} spec: terminationGracePeriodSeconds: 10 nodeSelector: k8s-meeting: true volumes: - name: log hostPath: path: /var/log/quanshi/{{name}} type: DirectoryOrCreate - name: conf configMap: name: {{name}} containers: - name: {{name}} image: {{image}} env: - name: NODE_IP valueFrom: fieldRef: fieldPath: status.hostIP - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP resources: limits: cpu: 2000m memory: 4000Mi requests: cpu: 100m memory: 150Mi securityContext: privileged: false volumeMounts: - name: log mountPath: /var/log/quanshi - name: conf mountPath: /mnt/conf
|
6. StatefulSet
为了解决有状态服务的部署问题,能做到有序部署,有序扩展,即 Pod 是有顺序的。在部署或者扩展的时候要依据定义的顺序依次依序进行(即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态)。
典型场景有:
- 数据库部署(如
MySQL),每个Pod都有一个稳定的网络标识和唯一的持久化存储卷,可以确保数据的持久性和一致性; - 消息队列(如
Kafka)每个Pod都有一个唯一的网络标识和持久化存储卷,确保消息的可靠性和持久化存储; - 分布式缓存(如
Redis),每个Pod都有一个唯一的网络标识和持久化存储卷,可以确保缓存数据的可靠性和一致性。
创建StatefulSet的配置示例:
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
| apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx
|
7. DaemonSet
保证在每台 Node 上都运行一个容器实例,供主机上的所有Pod共用。常用来部署一些集群的日志、监控或者其他系统管理应用,如syslog-ng, filebeat等。
1 2
| apiVersion: apps/v1 kind: DaemonSet
|
8. ConfigMap
用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。
典型使用场景:
- 配置注入:将应用程序的配置信息注入到容器中。通过将ConfigMap挂载到容器的文件系统中,应用程序可以读取ConfigMap中的配置数据并应用到运行时环境中。
- 动态配置更新:当应用程序的配置信息发生更改时,可以通过更新ConfigMap来实现动态配置更新。这样,无需重新构建和重新部署应用程序,就可以更新应用程序的配置。
- 环境变量注入:通过将ConfigMap的值设置为环境变量,可以将配置信息传递给应用程序作为环境变量。
- 共享配置:多个应用程序可以共享同一个ConfigMap,以便它们可以使用相同的配置信息。
创建ConfigMap的配置示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
| apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm game.properties: | enemies=aliens lives=3 secret.code.allowed=true secret.code.lives=30 ui.properties: | color.good=purple color.bad=yellow allow.textmode=true how.nice.to.look=fairlyNice
|
9. HPA
全称为Horizontal Pod Autoscaling,可以根据 CPU 使用率或应用自定义 metrics 自动扩展 Pod 数量。
CA(Cluster AutoScaler)用于提供Node级扩容,支持更高效的扩缩容。
CA可以和 HPA配合使用:
