K8S资源对象梳理

1. 容器应用创建

在 Kubernetes 中,容器应用的创建不仅仅依赖于 docker run 命令,还可以通过 Kubernetes 的资源对象进行创建和管理。Kubernetes 提供了类似 Docker 容器的功能,但与 Docker 容器不同的是,Kubernetes 会在集群中进行调度和管理。下面我会详细介绍一些 Docker 和 Kubernetes 中常见的创建容器的命令及参数,并与 Kubernetes 中的相关概念进行对比。

Docker 容器创建命令(示例)

docker run -d --name myapp -p 8080:80 -v /local/path:/container/path nginx
参数 说明
-d 在后台运行容器(detached mode)。
--name myapp 指定容器的名称为 myapp
-p 8080:80 将主机的 8080 端口映射到容器的 80 端口,用于外部访问。
-v /local/path:/container/path 将本地目录 /local/path 挂载到容器内的 /container/path,用于数据共享和持久化。
nginx 要运行的镜像名称,这里是 nginx 镜像。

Kubernetes 创建容器应用

Kubernetes 中并没有直接类似于 docker run 的命令,而是通过定义 PodDeployment 等资源对象来创建和管理容器。创建一个简单的应用容器一般通过创建一个 Deployment 来实现。

例如,创建一个 Nginx 应用的 Kubernetes 部署文件如下:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: html-volume
      volumes:
      - name: html-volume
        hostPath:
          path: /path/to/local/html

Kubernetes 相关指令和参数说明

在 Kubernetes 中,部署和管理容器应用时,使用的指令和参数不同于 Docker,但有类似的功能。以下是一些常见的 Kubernetes 对象及其相关参数说明。

Kubernetes 对象 说明
Pod Kubernetes 中最小的部署单位,每个 Pod 运行一个或多个容器。
Deployment 管理 Pod 副本的对象,负责自动扩展、更新、回滚等功能。
ReplicaSet 保证指定数量的 Pod 副本在运行。
Service 为一组 Pod 提供访问接口。通常与负载均衡一起使用。
Ingress 控制 HTTP 和 HTTPS 流量的进出。
ConfigMap 存储配置信息,供 Pod 使用。
Secret 存储敏感数据,如密码、证书等,供 Pod 使用。
PersistentVolume (PV) 为容器提供持久化存储。
PersistentVolumeClaim (PVC) 用户对存储资源的请求。

Kubernetes 中创建容器的常用命令

Kubernetes 使用命令行工具 kubectl 来创建、管理和调试容器应用。下面是一些常见的命令和参数:

命令 说明
kubectl apply -f <file> 通过 YAML 文件应用配置,创建或更新资源。
kubectl create deployment <name> --image=<image> 创建一个 Deployment 对象并运行指定镜像的容器。
kubectl get pods 列出所有 Pod 的状态。
kubectl describe pod <pod-name> 查看 Pod 的详细信息。
kubectl expose pod <pod-name> --port=<port> 为 Pod 创建一个 Service。
kubectl scale deployment <name> --replicas=<count> 扩展或缩减 Deployment 中的 Pod 副本数量。

Kubernetes 中常见的资源对象与 Docker 容器的对比

Docker Kubernetes
docker run kubectl create / kubectl apply
容器直接运行 容器通过 Pod 运行
通过端口映射实现访问 通过 Service 或 Ingress 访问 Pod
容器启动后手动管理 Kubernetes 自动调度和管理容器
没有内置的高可用机制 Kubernetes 提供了高可用性、扩展性、回滚等功能

通过上面的表格和解释,我们可以看到 Docker 和 Kubernetes 在容器创建和管理上的不同之处。Kubernetes 提供了更强大的集群管理功能,支持自动化部署、扩展、负载均衡、健康检查等。


2. Kubernetes 部署管理

Kubernetes 提供了一系列资源对象来帮助管理容器的生命周期和状态,这些资源可以自动化应用的部署、更新、扩展等。常见的 Kubernetes 资源对象有:DeploymentReplicaSetStatefulSetDaemonSetJobCronJob 等。

Deployment

Deployment 是 Kubernetes 中用于管理无状态应用的核心资源对象。它提供了丰富的功能,如自动扩展、滚动更新、回滚等,能够帮助开发者高效地管理应用。

Deployment 示例:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3  # 期望运行的 Pod 数量
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
参数 说明
replicas 指定要创建的 Pod 副本数量,Kubernetes 会根据该数量来管理 Pod。
selector 用于选择哪些 Pod 属于当前的 Deployment。一般使用标签选择器。
template 用于定义 Pod 的模板,包括容器、镜像、端口等配置。

ReplicaSet

ReplicaSet 用于确保指定数量的 Pod 副本在任何时刻都在运行。通常,Deployment 会使用 ReplicaSet 来管理 Pod 副本。

ReplicaSet 示例:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
参数 说明
replicas 指定期望的 Pod 数量,ReplicaSet 会确保这些 Pod 始终处于运行状态。
selector Deployment 中的 selector 类似,用于选择管理的 Pod。
template 定义 Pod 的模板,指定容器及其配置。

StatefulSet

StatefulSet 主要用于管理有状态应用,比如数据库。与 Deployment 不同,StatefulSet 可以确保每个 Pod 都有一个稳定的唯一标识和存储,这对有状态服务(如 MySQL、Redis)非常重要。

StatefulSet 示例:
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-statefulset
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
参数 说明
serviceName 创建的服务名称,确保访问 StatefulSet 中的 Pod 时保持一致。
replicas 指定 Pod 副本数量,Kubernetes 会根据需求调度 Pod。
volumeClaimTemplates 为每个 Pod 自动创建 PVC(PersistentVolumeClaim),确保每个 Pod 都有独立的存储。

DaemonSet

DaemonSet 用于在集群中的每个节点上运行一个 Pod。它通常用于日志收集、监控等场景。

DaemonSet 示例:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd
        ports:
        - containerPort: 24224
参数 说明
selector 用于选择运行的 Pod 标签。
template Deployment 中的 template 类似,定义 Pod 的模板。
replicas DaemonSet 会在集群中的每个节点上运行一个 Pod,因此不需要显式设置副本数量。

Job 和 CronJob

Job 用于运行一次性任务,并确保任务执行完毕。CronJob 则是在指定时间周期内执行任务,类似于 Linux 的 Cron 定时任务。

Job 示例:
apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: busybox
        command: ["echo", "Hello Kubernetes!"]
      restartPolicy: Never
参数 说明
template 用于定义 Job 中要运行的容器。
restartPolicy Job 完成后是否重启 Pod,Never 表示不重启。
CronJob 示例:
apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "0 * * * *"  # 每小时执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["echo", "Hello Kubernetes!"]
          restartPolicy: Never
参数 说明
schedule Cron 表达式,指定任务的执行周期。
jobTemplate 用于定义执行的 Job 模板。

总结

Kubernetes 提供的部署管理资源对象(如 DeploymentReplicaSetStatefulSetDaemonSet 等)帮助我们高效地管理容器应用的生命周期,支持高可用、自动扩展、回滚等功能。使用这些资源对象,我们可以轻松实现无状态应用的自动化部署、扩展和升级,也能支持有状态服务的管理。


3. Kubernetes 安全防护体系

Kubernetes 在安全方面提供了多种功能,帮助用户管理和保护容器应用,防止潜在的安全漏洞和攻击。这些功能包括网络安全、身份和访问控制、密钥管理、以及网络策略等。

网络安全

Kubernetes 提供了多种网络方案来确保集群中的容器应用之间的安全通信。常见的网络方案包括 FlannelCalicoCilium,这些方案为集群内部的容器提供了 IP 管理、网络策略以及数据加密等功能。

Flannel

Flannel 是 Kubernetes 中常用的容器网络插件(CNI,Container Network Interface),它的主要功能是为容器分配 IP 地址,并在节点之间传递容器之间的流量。

特性 说明
简单的网络设计 Flannel 使用了 Overlay 网络,确保跨节点的容器能够通信。
支持多种后端 Flannel 支持不同的网络后端,如 VXLAN 和 UDP。
网络隔离 通过使用 Flannel 可以为不同的 Pod 和服务提供不同的 IP 地址,保证容器间的隔离。
Calico

Calico 是一个强大的网络插件,除了提供 IP 地址管理外,还具有强大的网络策略和安全功能,特别适用于需要网络策略控制的企业级环境。

特性 说明
高性能 Calico 使用了基于 BGP(边界网关协议)的路由设计,适用于高吞吐量场景。
网络策略 Calico 支持在网络层对 Pod 进行细粒度的访问控制,用户可以定义哪些 Pod 可以相互通信。
集群间通信 支持跨集群的网络通信,帮助不同 Kubernetes 集群间的容器进行通信。
Cilium

Cilium 是一个使用 eBPF 技术的网络插件,提供了更加灵活和高效的网络安全策略。它通过在内核中直接运行代码,实现高效的流量过滤和网络监控。

特性 说明
基于 eBPF 使用 eBPF(扩展 Berkeley 数据过滤)技术进行数据包过滤,提供更高的性能和灵活性。
高级安全功能 Cilium 可以控制容器的访问权限,确保容器只能访问符合规定的服务。
负载均衡与流量监控 提供内建的负载均衡功能,并支持流量监控和审计。

网络策略

在 Kubernetes 中,NetworkPolicy 允许用户控制 Pod 之间的通信,定义哪些 Pod 能够访问其他 Pod。通过使用网络策略,用户可以限制容器的访问范围,保护关键应用和服务。

NetworkPolicy 示例:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx-to-db
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 3306
参数 说明
podSelector 用于选择网络策略应用的 Pod。
ingress 定义允许进入 Pod 的流量,from 指定哪些 Pod 或 IP 可以访问该 Pod。
ports 指定 Pod 可以接受的端口和协议,这里定义了允许访问的 TCP 端口。

通过定义网络策略,管理员可以有效地隔离不同应用的流量,防止未授权的访问。

身份和访问控制

Kubernetes 提供了 RBAC (Role-Based Access Control) 来控制不同用户和服务对 Kubernetes 资源的访问权限。RBAC 可以帮助管理员精细化管理权限,确保只有授权的用户或服务能够访问集群中的敏感资源。

RBAC(角色访问控制)

RBAC 允许 Kubernetes 中的资源访问和操作基于角色来管理,角色(Role)定义了可以执行的操作,而角色绑定(RoleBinding)将角色与用户或服务账户进行关联。

Role 示例:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
参数 说明
apiGroups 定义资源所属的 API 组,空字符串代表核心 API 组。
resources 定义可以操作的资源类型,这里是 pods
verbs 定义可以执行的操作,getlist 表示可以获取和列出 Pod 信息。
RoleBinding 示例:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "janedoe"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
参数 说明
subjects 定义哪些用户、组或服务账户具有该角色的权限。
roleRef 指定角色的引用,表示 janedoe 用户具有 pod-reader 角色。

通过 RBAC,Kubernetes 能够提供强大的访问控制,帮助管理员确保集群资源的安全性。

敏感数据管理

Kubernetes 提供了 Secrets 对象,用于存储和管理敏感数据,如数据库密码、API 密钥等。Secrets 数据在 Kubernetes 中是经过 Base64 编码存储的,但在配置文件中需要小心使用。

Secret 示例:
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2Vy  # base64 编码的用户名
  password: cGFzc3dvcmQ=  # base64 编码的密码
参数 说明
data 存储敏感数据,数据需要进行 Base64 编码。
type 定义 Secret 的类型,Opaque 是最常见的类型,表示没有特定格式。
Secret 使用示例(挂载到 Pod)
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    envFrom:
    - secretRef:
        name: my-secret
参数 说明
envFrom 通过 secretRef 将 Secret 的内容作为环境变量传递给容器。

通过 Secrets,Kubernetes 可以确保敏感数据的安全存储和访问。


总结

Kubernetes 的安全防护体系为集群提供了多层次的保护,从网络层到身份和访问控制,再到敏感数据的管理,每一部分都有专门的资源和策略来确保应用的安全性。通过合理使用 网络策略RBACSecrets 等功能,Kubernetes 可以有效地防止未经授权的访问、保护敏感数据并确保容器间的安全通信。


4. Kubernetes 网络解决方案

Kubernetes 通过提供多种网络解决方案和服务暴露方式,帮助用户实现集群内外的网络通信。常见的网络方案有 FlannelCalicoCilium 等,以及 ServiceIngressNetworkPolicy 等网络资源对象,确保集群中的容器能够安全、稳定地进行通信。

Kubernetes 服务暴露

在 Kubernetes 中,Service 是暴露 Pod 服务的主要资源对象。通过 Service,用户可以在集群内和集群外访问运行在 Pod 中的应用。

Service 类型:
类型 说明
ClusterIP 默认类型,只能在集群内访问,适用于集群内部的服务通信。
NodePort 在每个节点的指定端口上暴露服务,使得集群外部可以通过节点的 IP 地址和端口访问服务。
LoadBalancer 将服务暴露给外部,支持负载均衡,通过云提供商的负载均衡器实现外部访问。
ExternalName 将服务映射到外部 DNS 名称,使得 Kubernetes 内部可以访问外部服务。
Service 示例:
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP
参数 说明
selector 用于选择目标 Pod,通常根据标签选择。
ports 定义服务的端口映射。port 是对外暴露的端口,targetPort 是 Pod 中容器实际监听的端口。
type 服务类型,决定了服务如何暴露。

Ingress 控制

Ingress 是 Kubernetes 提供的一种 HTTP 和 HTTPS 流量路由机制,允许用户定义外部访问集群内应用的规则。Ingress 控制器(如 Nginx、Traefik)负责将请求转发到对应的服务。

Ingress 示例:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80
参数 说明
host 定义服务的访问域名。
http 定义基于 HTTP 的路由规则。
paths 定义路径匹配规则,用于将请求转发到指定的服务。
backend 定义请求转发的目标服务和端口。
Ingress 控制器

Ingress 控制器是用于管理 Ingress 资源的组件,常见的控制器有:

控制器 说明
Nginx Ingress Controller 使用 Nginx 作为负载均衡器和反向代理,实现流量路由和负载均衡。
Traefik 另一种常用的 Ingress 控制器,具有自动发现服务的功能,支持动态配置。
HAProxy 强大的负载均衡器,也可以作为 Ingress 控制器使用。

Kubernetes 网络插件

Kubernetes 支持多种网络插件(CNI 插件)来实现容器之间的网络通信。常见的 CNI 插件包括 FlannelCalicoCilium 等。

Flannel

Flannel 是 Kubernetes 中最常用的网络插件之一,提供了一个简单的 Overlay 网络方案,使得集群内的 Pod 能够跨节点通信。Flannel 使用 VXLAN 或 UDP 协议来封装跨节点的网络流量。

特性 说明
Overlay 网络 Flannel 创建一个虚拟网络,将 Pod 的网络流量封装在另一个网络中进行传输。
简单配置 Flannel 配置简单,适合快速部署。
Calico

Calico 是一个功能强大的网络插件,不仅提供容器间通信,还支持细粒度的网络策略控制。Calico 使用 BGP(边界网关协议)来进行路由,提供高效的网络性能。

特性 说明
网络策略 支持对容器通信的细粒度控制,可以根据标签、IP 地址等条件制定规则。
高性能 使用 BGP 协议,Calico 提供高效的网络性能,适用于大规模集群。
集群间通信 Calico 可以跨多个 Kubernetes 集群进行通信,提供全局网络策略支持。
Cilium

Cilium 使用 eBPF(扩展的 Berkeley 数据包过滤)技术,提供了强大的网络安全功能。它通过在内核中执行代码来过滤数据包,能够在数据包流通过时进行深度检测。

特性 说明
基于 eBPF eBPF 技术能够提供高性能的包过滤和网络监控功能。
网络安全 提供网络流量的深度监控和控制,可以实现高效的访问控制和安全策略。
负载均衡 Cilium 提供内建的负载均衡功能,支持多种流量转发和调度策略。

Kubernetes 中的 NetworkPolicy

Kubernetes 的 NetworkPolicy 资源对象用于控制 Pod 之间的流量。通过 NetworkPolicy,用户可以定义哪些 Pod 可以与其他 Pod 通信,从而实现网络隔离和安全控制。

NetworkPolicy 示例:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-db
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 3306
参数 说明
podSelector 选择哪些 Pod 应用该网络策略。
ingress 定义进入 Pod 的流量来源,这里限制了只有来自 database 应用的 Pod 可以访问 web 应用。
ports 指定允许访问的端口。

通过使用 NetworkPolicy,用户可以控制集群内不同服务之间的流量,防止未授权访问。


总结

Kubernetes 提供了多种网络解决方案,帮助用户实现集群内外的网络通信、流量路由、负载均衡和安全控制。通过合理使用 ServiceIngressNetworkPolicy 等网络资源对象,用户可以灵活地管理集群内的网络流量,并确保服务的高可用性和安全性。


5. Kubernetes 资源管理

Kubernetes 提供了多种资源管理机制,以帮助用户管理容器的持久化存储、配置、密钥等。常见的资源管理对象有 ConfigMapSecretPersistentVolume (PV)PersistentVolumeClaim (PVC)Volume 等。

持久化存储管理

在 Kubernetes 中,Pod 的存储是临时的。如果 Pod 被销毁,存储的数据也会丢失。因此,需要使用持久化存储来保证数据在 Pod 重启后仍然可用。Kubernetes 提供了 PersistentVolume (PV)PersistentVolumeClaim (PVC) 来帮助用户管理存储资源。

PersistentVolume (PV)

PersistentVolume 是 Kubernetes 中的存储资源,它代表了集群中的一块存储区域,通常由管理员预先配置。PV 可以绑定到多个 Pod,保证数据的持久化。

PV 示例:
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /mnt/data
参数 说明
capacity 指定 PV 的存储容量,这里设置为 10Gi。
volumeMode 定义存储的模式,通常为 Filesystem,表示以文件系统方式访问。
accessModes 定义对存储的访问模式,ReadWriteOnce 表示只能由一个节点读写。
persistentVolumeReclaimPolicy 定义 PV 的回收策略,Retain 表示手动删除 PV。
storageClassName 存储类,用于指定存储类型。
hostPath 指定存储的实际位置,这里使用本地路径 /mnt/data
PersistentVolumeClaim (PVC)

PersistentVolumeClaim 是用户请求存储的资源对象。PVC 可以绑定到 PV,允许 Pod 使用这些存储资源。

PVC 示例:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
参数 说明
accessModes 定义 PVC 对存储的访问模式,必须与 PV 匹配。
resources 定义存储请求的容量,这里请求 5Gi。
storageClassName 存储类,要求与 PV 的存储类匹配。

通过 PVC,用户可以请求指定大小和类型的存储资源,Kubernetes 会自动寻找符合要求的 PV 进行绑定。

Volume

Volume 是 Pod 中存储的抽象,它支持多种存储类型(如 emptyDir、hostPath、NFS 等)。通过 Volume,容器可以在 Pod 内部共享数据,或者与外部系统交互。

Volume 示例:
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: nginx-volume
  volumes:
  - name: nginx-volume
    hostPath:
      path: /data/nginx
参数 说明
volumeMounts 定义容器中挂载的 Volume,以及挂载路径。
volumes 在 Pod 中定义 Volume,并指定类型。这里使用了 hostPath 类型的 Volume。

配置管理:ConfigMap 和 Secret

在 Kubernetes 中,配置文件、环境变量和敏感数据(如密码、证书等)需要通过专门的资源对象来管理。ConfigMapSecret 是 Kubernetes 提供的两种资源对象,用于分别管理普通配置数据和敏感数据。

ConfigMap

ConfigMap 用于存储非敏感的配置信息,可以将配置项作为环境变量或文件挂载到容器中。

ConfigMap 示例:
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    key1=value1
    key2=value2
参数 说明
data 配置信息存储区域,可以是键值对或文件内容。
ConfigMap 挂载到 Pod:
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: app-image
    envFrom:
    - configMapRef:
        name: app-config
参数 说明
envFrom 通过 configMapRefConfigMap 的内容作为环境变量传递给容器。
Secret

Secret 用于存储敏感数据,如密码、OAuth 令牌等。在 Kubernetes 中,Secret 会被以加密形式存储,并可以作为环境变量或文件挂载到容器中。

Secret 示例:
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2Vy  # base64 编码的用户名
  password: cGFzc3dvcmQ=  # base64 编码的密码
参数 说明
data 存储敏感数据,数据必须是 Base64 编码格式。
Secret 挂载到 Pod:
apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
  - name: secret-container
    image: secret-image
    envFrom:
    - secretRef:
        name: my-secret
参数 说明
envFrom 通过 secretRef 将 Secret 中的内容作为环境变量传递给容器。

资源配额和限额

Kubernetes 允许设置资源配额(ResourceQuota)和资源限制(LimitRange),以确保集群中的资源能够被合理利用,防止某个用户或应用占用过多资源。

ResourceQuota 示例:
apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota
spec:
  hard:
    cpu: "4"
    memory: 10Gi
参数 说明
cpu 指定 CPU 使用的硬限制,这里设置为 4 个 CPU 核心。
memory 设置内存使用的硬限制,这里设置为 10Gi。
LimitRange 示例:
apiVersion: v1
kind: LimitRange
metadata:
  name: container-limit
spec:
  limits:
  - max:
      cpu: "2"
      memory: 4Gi
    min:
      cpu: "500m"
      memory: 1Gi
    type: Container
参数 说明
max 定义容器允许使用的最大 CPU 和内存。
min 定义容器允许使用的最小 CPU 和内存。

总结

Kubernetes 提供了强大的资源管理功能,帮助用户在集群中管理存储、配置和敏感数据。通过使用 PersistentVolumePersistentVolumeClaim,用户可以高效管理持久化存储;通过 ConfigMapSecret,可以方便地管理应用配置和敏感信息。同时,资源配额和限制机制确保了集群资源的合理分配和利用。


6. Kubernetes 大规模应用管理

Kubernetes 的强大之处在于它能够有效地管理大规模的容器化应用,提供高可用、自动扩展、负载均衡等功能。在大规模部署中,Kubernetes 提供了很多机制来帮助用户应对不同规模的应用需求,包括 自动扩展(Auto Scaling)滚动更新(Rolling Update)高可用(High Availability)分布式部署(Distributed Deployment) 等。

高可用架构

Kubernetes 通过以下几种方式来确保应用的高可用性:

  1. Pod 副本(ReplicaSet):通过指定 Pod 副本数,Kubernetes 会确保在集群中始终有指定数量的 Pod 副本运行。当某个 Pod 出现故障或不可用时,Kubernetes 会自动重新调度 Pod 到健康的节点上,保持服务的高可用性。
  2. Deployment 和 ReplicaSet:使用 Deployment 可以定义应用的版本和期望副本数,Kubernetes 会根据这些定义自动进行滚动更新或回滚,确保应用始终处于可用状态。
  3. Service:通过 Service,Kubernetes 提供了负载均衡功能,确保请求能够均匀地分发到多个 Pod 实例,从而提高服务的可用性和稳定性。
Deployment 示例:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
参数 说明
replicas 指定部署的 Pod 副本数,这里设置为 5,意味着集群中会有 5 个 Nginx Pod 实例。
selector 选择器,用于指定哪些 Pod 是 Deployment 管理的对象。
template Pod 模板,定义了容器的镜像和端口。

自动扩展(Auto Scaling)

Kubernetes 提供了自动扩展功能,能够根据负载动态调整 Pod 的副本数和资源的使用。

  1. Horizontal Pod Autoscaler (HPA):HPA 根据指定的指标(如 CPU 使用率或请求数)自动调整 Pod 副本数。例如,如果某个 Pod 的 CPU 使用率过高,Kubernetes 会自动增加 Pod 副本数,以便处理更高的负载。
Horizontal Pod Autoscaler 示例:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
参数 说明
scaleTargetRef 指定自动扩展的目标对象,这里选择了 nginx-deployment
minReplicas 指定 Pod 副本的最小数量。
maxReplicas 指定 Pod 副本的最大数量。
metrics 设定自动扩展的触发条件,这里是根据 CPU 使用率进行扩展。
  1. Vertical Pod Autoscaler (VPA):VPA 根据 Pod 的资源需求(如 CPU 和内存)自动调整 Pod 的资源请求和限制,确保 Pod 能够在不同负载下获得适当的资源。

滚动更新(Rolling Update)

滚动更新是 Kubernetes 提供的一种零停机时间更新方式。在执行滚动更新时,Kubernetes 会逐步替换旧版本的 Pod 实例为新版本,而不会同时停用所有 Pod,从而保证服务的持续可用性。

Deployment 滚动更新过程:
  1. 创建新的 Deployment 或更新现有的 Deployment。
  2. Kubernetes 自动启动新的 Pod 副本,并逐步替换旧的 Pod 实例。
  3. 通过 kubectl rollout 命令,可以监控滚动更新的状态。
命令:
bash

复制编辑
kubectl rollout status deployment/nginx-deployment
命令 说明
kubectl rollout status 查看滚动更新的进度。
kubectl rollout undo 回滚 Deployment 到上一个版本。

分布式部署与负载均衡

Kubernetes 支持在多节点上进行分布式部署,并通过 Service 对外提供负载均衡功能。通过将多个 Pod 部署在不同的节点上,Kubernetes 可以在节点发生故障时自动将流量路由到其他健康的节点,保证服务的高可用性。

  1. Service 和负载均衡:Kubernetes 中的 Service 会自动创建一个负载均衡器,将外部流量均匀分发到集群内的 Pod 上。
  2. NodePort 和 LoadBalancer:对于需要暴露到外部网络的服务,NodePortLoadBalancer 类型的 Service 可以帮助用户实现集群外部的负载均衡。

Kubernetes 高可用集群

Kubernetes 支持高可用集群配置,通常包括以下几个方面:

  1. 多个 Master 节点:在生产环境中,通常会部署多个 Master 节点,避免单点故障。
  2. etcd 集群:Kubernetes 的配置存储使用 etcd,通过配置 etcd 集群来实现高可用。
  3. Pod 反亲和性:通过配置 Pod 的反亲和性(Pod Anti-Affinity),确保 Pod 不会调度到同一个节点上,从而避免单点故障。

高可用 Master 节点配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: master-deployment
spec:
  replicas: 3  # 部署 3 个 Master 节点实现高可用
  selector:
    matchLabels:
      role: master
  template:
    metadata:
      labels:
        role: master
    spec:
      containers:
      - name: master
        image: k8s-master:latest
参数 说明
replicas 设置 Master 节点的副本数,这里设置为 3,确保集群在某个节点故障时依然可用。
selector 用于选择应用该配置的节点标签。
template 定义 Pod 的模板,确保所有 Master 节点使用相同的配置。

多区域/多集群部署

在大型分布式系统中,Kubernetes 还可以通过多个集群实现跨地域的高可用架构。多个集群之间的通信可以通过 Federation(集群联邦)技术来实现,允许跨集群的资源调度和管理。


总结

Kubernetes 提供了非常强大的大规模应用管理功能,确保应用可以在全球范围内进行弹性扩展和高可用性部署。通过自动扩展、滚动更新和高可用集群配置,Kubernetes 能够帮助用户高效地管理大规模的容器化应用,保证服务的稳定性和性能。


7. Kubernetes 监控与日志管理

Kubernetes 集群的运行和维护需要实时的监控和日志管理,确保应用和服务能够在集群中高效稳定地运行。Kubernetes 提供了多种内建和外部的工具来帮助用户进行集群监控、日志收集和分析。

Kubernetes 监控

Kubernetes 监控主要包括对集群的资源使用情况、Pod 的健康状态、节点的负载情况等进行监控。常见的 Kubernetes 监控工具有 PrometheusGrafana,它们一起可以提供全面的监控和可视化功能。

Prometheus

Prometheus 是一个开源的监控工具,广泛用于 Kubernetes 集群的监控。它通过采集指标数据(Metrics),并通过时间序列数据库存储这些数据,支持告警、查询和可视化。

  1. Prometheus 部署

可以通过 Helm(Kubernetes 的包管理工具)或者直接使用 YAML 文件来部署 Prometheus。以下是一个简单的 Prometheus 部署示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.31.2
        ports:
        - containerPort: 9090
参数 说明
replicas 设置 Prometheus 的副本数,通常设置为 1 或更多来确保高可用。
image 使用的 Prometheus 镜像,这里是 prom/prometheus:v2.31.2
ports Prometheus 提供 Web UI,默认端口为 9090。
  1. Prometheus 服务暴露

为了方便访问 Prometheus 的 Web UI,可以使用 Kubernetes 的 Service 对 Prometheus 进行暴露:

apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
spec:
  selector:
    app: prometheus
  ports:
    - protocol: TCP
      port: 9090
      targetPort: 9090
  type: ClusterIP
参数 说明
selector 用于选择 Prometheus 的 Pod。
ports 将端口 9090 映射到服务,便于访问 Prometheus 的 Web UI。
Grafana

Grafana 是一个开源的分析和可视化平台,通常与 Prometheus 配合使用,用于展示实时的监控数据和告警。Grafana 通过读取 Prometheus 收集的数据来生成丰富的可视化图表。

  1. Grafana 部署

以下是一个 Grafana 部署的简单示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:v8.2.5
        ports:
        - containerPort: 3000
参数 说明
image 使用的 Grafana 镜像,这里是 grafana/grafana:v8.2.5
ports Grafana 的 Web UI 默认在 3000 端口提供。
  1. Grafana 服务暴露

可以通过 Service 来暴露 Grafana,以便外部访问其可视化界面:

apiVersion: v1
kind: Service
metadata:
  name: grafana-service
spec:
  selector:
    app: grafana
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: ClusterIP
参数 说明
selector 选择 Grafana Pod。
ports 将端口 3000 映射到服务,便于外部访问 Grafana 的 Web UI。
Metrics Server

Metrics Server 是 Kubernetes 用于收集集群内节点和 Pod 资源使用情况的工具,通常与 HPA(Horizontal Pod Autoscaler)结合使用,来自动扩展 Pod 数量。它提供了集群内各节点、Pod 的 CPU 和内存使用情况。

  1. Metrics Server 部署

以下是部署 Metrics Server 的 YAML 示例:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: metrics-server
  template:
    metadata:
      labels:
        app: metrics-server
    spec:
      containers:
      - name: metrics-server
        image: k8s.gcr.io/metrics-server/metrics-server:v0.5.0
        ports:
        - containerPort: 443
参数 说明
replicas 设置 Metrics Server 的副本数。
image 使用的 Metrics Server 镜像。

Kubernetes 日志管理

Kubernetes 中的日志管理是容器化应用监控和故障排查的关键部分。通过集中式的日志收集系统,用户可以方便地查看应用容器的日志,进行故障诊断。常见的日志管理工具有 FluentdElasticsearchKibana(简称 EFK 堆栈)和 Loki(与 Grafana 配合使用)。

Fluentd 与 EFK 堆栈

Fluentd 是一个开源的数据收集器,用于收集、处理和转发日志数据。通常,Fluentd 会与 Elasticsearch 和 Kibana 配合使用,形成 EFK 堆栈。

  1. Fluentd 部署

Fluentd 作为日志收集器,可以部署在 Kubernetes 集群中,负责收集各个 Pod 和容器的日志,并将其发送到 Elasticsearch 进行存储和索引。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fluentd
spec:
  replicas: 2
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.12.0
        ports:
        - containerPort: 24224
参数 说明
replicas Fluentd 的副本数,通常设置为 2 或更多来确保高可用性。
image Fluentd 使用的 Docker 镜像。
Elasticsearch 和 Kibana

Elasticsearch 用于存储和索引日志数据,Kibana 提供了可视化界面,帮助用户查询和分析日志数据。

  1. Elasticsearch 部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: elasticsearch
spec:
  replicas: 1
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
      - name: elasticsearch
        image: docker.elastic.co/elasticsearch/elasticsearch:7.10.0
        ports:
        - containerPort: 9200
参数 说明
image Elasticsearch 镜像,指定版本为 7.10.0。
  1. Kibana 部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kibana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kibana
  template:
    metadata:
      labels:
        app: kibana
    spec:
      containers:
      - name: kibana
        image: docker.elastic.co/kibana/kibana:7.10.0
        ports:
        - containerPort: 5601
参数 说明
image Kibana 镜像,指定版本为 7.10.0。

通过使用 EFK 堆栈(Fluentd + Elasticsearch + Kibana),用户可以实现集群内的日志收集、存储、分析和可视化,快速定位和解决问题。


总结

Kubernetes 提供了强大的监控和日志管理功能,帮助用户实时监控集群的健康状态、资源使用情况,以及收集容器应用的日志。通过 PrometheusGrafanaMetrics ServerEFK 堆栈,用户可以实现全面的监控、告警和日志分析,确保集群的稳定性和应用的高可用性。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。
k8s

外网访问minikube内的pod

2022-6-5 17:01:28

DB

SQL DB - 关系型数据库是如何工作的

2023-3-8 8:40:48

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧