前一篇文章我们介绍了K8s的概念理解和常用命令,这篇我们重点介绍K8s的资源组件和相关配置使用。
Node:
是 Pod 真正运行的主机,可以是物理机,也可以是虚拟机。为了管理 Pod,每个 Node 节点上至少要运行 container runtime(比如 docker, rkt, containerd)、kubelet 和 kube-proxy 服务。
Pod:
是一组紧密关联的容器集合(也可以是单个容器),它们共享 IPC(进程间通信) , Network namespace 和 文件存储(需挂载到容器),是 Kubernetes 调度的基本单位。
Node和Pod的关系如下图所示:
上图中的Node中共有4个Pod,分别为:
是对一组资源和对象的抽象集合,相当于给k8s系统内部的对象划分一些命名空间。常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的(默认是 default)。
创建命名空间的配置示例:
apiVersion: v1
kind: Namespace # 表示要创建的资源类型为命名空间
metadata:
name: test # 命名空间名称为test
命名空间的使用则是通过Pod或Service中的
metadata.namespace
字段来声明。
是应用服务的抽象,为应用提供负载均衡和服务发现。它通过将多个 Pod IP 和端口列表组成 endpoints,由 kube-proxy 负责将服务 IP 负载均衡到这些 endpoints 上。
每个 Service 都会自动分配一个 cluster IP(仅在集群内部可访问的虚拟地址)和 DNS 名,其他容器可以通过该地址或 DNS 来访问服务,而不需要了解后端容器的运行。
kind: Service # 创建的资源类型为服务
apiVersion: v1
metadata: # 资源的元数据
name: {{name}} # 服务名称
namespace: {{namespace}} # 所属namespace
spec: # 指定服务的规格,包括选择器和端口
selector: # 用于指定服务所选择的Pod的标签
k8s-app: {{name}} # 选择具有标签k8s-app且值为占位符{{name}}的Pod
ports: # 指定服务的端口映射规则
- name: serviceport # 定义了一个名为serviceport的端口映射,将容器内的8081端口映射到服务的端口8081上
protocol: TCP
port: 8081 # 服务对外开放的访问端口
targetPort: 8081 # 容器内端口
为进入集群的请求提供路由规则的集合,类似于反向代理Nginx的作用,它可以按规则将请求路由到具体的Service上。
Ingress模型如下图示例:
创建Ingress的配置规则:
apiVersion: extensions/v1beta1
kind: Ingress # 创建的资源类型为Ingress
metadata:
name: test
spec: # 指定Ingress的规格,包括规则(rules)
rules:
- host: foo.bar.com # 请求的主机名,会用于Request中的Host头过滤
http: # 使用http协议
paths: # 请求路径配置
- backend: # 指定要请求的后端服务
serviceName: s1 # 后端服务名称
servicePort: 80 # 后端服务端口
- host: bar.foo.com
http:
paths:
- backend:
serviceName: s2
servicePort: 80
用于无状态 Pod 部署声明,这些Pod对部署顺序没有要求(如nginx),可以定义 Pod 的副本数量,调度策略等,是最常用的一种部署方式,一般将 Pod 的定义内置在 Deployment 中。
Deployment的配置规则示例:
apiVersion: apps/v1
kind: Deployment # 创建的资源类型为Deployment
metadata:
name: {{name}}
namespace: {{namespace}}
spec: # Deployment的规格,包括副本数(replicas)、选择器(selector)、模板(template)等。
replicas: 2 # 创建2个pod副本
selector: # 选择Pod的条件配置
matchLabels:
k8s-app: {{name}} # 选择具有标签k8s-app且值为占位符{{name}}的Pod
template: # 用于定义Pod的模板
metadata:
labels: # 设置Pod的标签
k8s-app: {{name}}
spec:
terminationGracePeriodSeconds: 10 # Pod的优雅终止期限为10秒
nodeSelector:
k8s-meeting: true # 按需调整
volumes: # 定义了两个存储卷log和conf
- name: log
hostPath: # 使用主机磁盘路径/var/log/quanshi/{{name}}进行挂载, 类型为目录或创建目录
path: /var/log/quanshi/{{name}}
type: DirectoryOrCreate
- name: conf
configMap: # 使用名称为{{name}}的ConfigMap配置数据进行挂载
name: {{name}}
containers: # 容器定义,名称和镜像均使用占位符表示
- name: {{name}} # 容器名称
image: {{image}} # 容器使用的镜像名称
env: # 注入到系统的环境变量,程序能读到,每个Pod可以不同
- 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 # 2个CPU核心
memory: 4000Mi # 4000Mi=4GB
requests: # 表示容器部署需要的最小资源
cpu: 100m # 占用一个CPU核心的1/10, 1C=1000m
memory: 150Mi # 150MB
securityContext: # 容器特权配置,有一些特殊的场景需要配置,例如syslog
privileged: false
volumeMounts: # 指定容器中的挂载卷和挂载路径
- name: log # 卷log(上面有指定)挂载到容器的/var/log/quanshi目录下
mountPath: /var/log/quanshi
- name: conf # 卷conf(上面有指定)挂载到容器的/mnt/conf目录下
mountPath: /mnt/conf
为了解决有状态服务的部署问题,能做到有序部署,有序扩展,即 Pod 是有顺序的。在部署或者扩展的时候要依据定义的顺序依次依序进行(即从 0 到 N-1,在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态)。
典型场景有:
- 数据库部署(如
MySQL
),每个Pod都有一个稳定的网络标识和唯一的持久化存储卷,可以确保数据的持久性和一致性;- 消息队列(如
Kafka
)每个Pod都有一个唯一的网络标识和持久化存储卷,确保消息的可靠性和持久化存储;- 分布式缓存(如
Redis
),每个Pod都有一个唯一的网络标识和持久化存储卷,可以确保缓存数据的可靠性和一致性。
创建StatefulSet的配置示例:
apiVersion: v1
kind: Service # 先定义一个Service,供下文的StatefulSet使用
metadata:
name: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None # None表示不分配集群IP
selector: # 选择具有标签app: nginx的Pod与该Service关联
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet # 创建的资源类型为StatefulSet
metadata:
name: web
spec:
serviceName: "nginx" # 指定StatefulSet关联的Service名称为nginx
replicas: 2 # StatefulSet的副本数为2,即创建2个Pod。
selector:
matchLabels: # 通过标签选择器来选择要关联的Pod。
app: nginx
template: # StatefulSet创建Pod时的模板
metadata:
labels: # 设置Pod的标签为app: nginx
app: nginx
spec:
containers: # 定义Pod中的容器名称和镜像名称
- name: nginx
image: nginx
保证在每台 Node 上都运行一个容器实例,供主机上的所有Pod共用。常用来部署一些集群的日志、监控或者其他系统管理应用,如syslog-ng, filebeat等。
apiVersion: apps/v1
kind: DaemonSet
用于保存配置数据的键值对,可以用来保存单个属性,也可以用来保存配置文件。
典型使用场景:
- 配置注入:将应用程序的配置信息注入到容器中。通过将ConfigMap挂载到容器的文件系统中,应用程序可以读取ConfigMap中的配置数据并应用到运行时环境中。
- 动态配置更新:当应用程序的配置信息发生更改时,可以通过更新ConfigMap来实现动态配置更新。这样,无需重新构建和重新部署应用程序,就可以更新应用程序的配置。
- 环境变量注入:通过将ConfigMap的值设置为环境变量,可以将配置信息传递给应用程序作为环境变量。
- 共享配置:多个应用程序可以共享同一个ConfigMap,以便它们可以使用相同的配置信息。
创建ConfigMap的配置示例:
apiVersion: v1
kind: ConfigMap # 创建的资源类型为ConfigMap
metadata:
name: special-config # ConfigMap的名称为special-config
namespace: default # ConfigMap所属的命名空间为default
data:
special.how: very # 定义了一个键值对,键为special.how,值为very
special.type: charm # 定义了一个键值对,键为special.type,值为charm。
game.properties: | # 定义了一个键值对,键为game.properties,值为多行文本。
enemies=aliens # game.properties内部定义一个配置项,键为enemies,值为aliens
lives=3
secret.code.allowed=true
secret.code.lives=30
ui.properties: | # 定义了一个键值对,键为ui.properties,值为多行文本。
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
全称为Horizontal Pod Autoscaling,可以根据 CPU 使用率或应用自定义 metrics 自动扩展 Pod 数量。
CA(Cluster AutoScaler)用于提供Node级扩容,支持更高效的扩缩容。