k8s核心资源对象一（入门到精通）

本文将深入探讨Kubernetes中的核心资源对象，包括Pod、Deployment、Service、Ingress、ConfigMap和Secret，详细解析其概念、功能以及实际应用场景，帮助读者全面掌握这些关键组件的使用方法。

一、pod

1 pod概念

k8s最小调度单元，可以包含一个或多个容器。同一个pod的容器可以共享网络和存储。

2 pod示例

[root@master-1 pod]# cat 02-pods-nginx.yaml 
apiVersion: v1
kind: Pod
metadata:name: linux86-web
spec:containers:- name: webimage: nginx:1.24.0-alpineports:- containerPort: 80
[root@master-1 pod]# kubectl apply -f 02-pods-nginx.yaml
[root@master-1 pod]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
linux86-web   1/1     Running   0          82s   10.100.2.4   worker233   <none>           <none>
[root@master-1 pod]# curl -I  10.100.2.4

二、deployment

1 介绍

Deployment是用于部署服务的资源，是最常用的控制器

管理RS，通过RS资源创建Pod;
具有上线部署，副本设置，滚动升级，回滚等功能；
提供声明式更新，即可以使用apply命令进行更新镜像版本之类的;

2 更新策略

蓝绿发布：不停止旧版本，直接部署新版本,新版本测试没有问题，就切换到新版本。
优点：无需停机，风险较小
缺点：切换是全量的，如果新版本有问题，则对用户体验有直接影响，需要双倍机器资源
灰度发布：旧版本和新版本共存
将新版本部署到一部分生产环境，让一部分用户先试用，如果没有问题，再逐步扩大范围，把全部服务都切换到新环境。
优点：用户体验影响小，灰度发布过程出现问题只影响部分用户
滚动更新：平滑地将服务更新

3 Deployment滚动发布

[root@master231 deployments]# cat 02-deploy-nginx-strategy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:name: deploy-nginx-strategy
spec:# 定义升级策略strategy:# 指定升级类型,有效值为Recreate和RollingUpdate.#    Recreate:#       先删除所有旧的Pod，再创建新的Pod。#    RollingUpdate:#       先删除部分旧的Pod，滚动更新旧的Pod，逐步使用新的Pod替代旧的Pod。#       默认就是基于滚动更新类型。# type: Recreatetype: RollingUpdate# 滚动更新rollingUpdate:# 在升级过程中，在原有旧的Pod基础之上启动的Pod数量。maxSurge: 2# 在升级过程中，指定最大不可用的数量。maxUnavailable: 1#maxSurge: "20%"#maxUnavailable: "10%"replicas: 5selector:matchExpressions:- key: appsvalues: - "v1"- "v2"operator: Intemplate:metadata:labels:apps: v1school: liuxspec:containers:- name: v1# image: harbor.liux.com/liux-apps/apps:v1image: harbor.liux.com/liux-apps/apps:v2imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:name: deploy-strategy
spec:type: NodePortselector:apps: v1school: liuxports:- port: 8888targetPort: 80nodePort: 30000
[root@master231 deployments]# 
升级过程
-------------> 第一波
旧的pod: 4
新的pod: 3 -------------> 第二波
旧的pod: 1
新的新的: 3  + 2[root@master231 deployments]# kubectl apply -f 02-deploy-nginx-strategy.yaml 
deployment.apps/deploy-nginx configured
service/deploy-strategy unchanged
[root@master231 deployments]# kubectl get po,svc -o wide
#切换版本
[root@master231 deployments]# vim 02-deploy-nginx-strategy.yaml #image: harbor.liux.com/liux-apps/apps:v1image: harbor.liux.com/liux-apps/apps:v2

4.Deloyment蓝绿发布

4.1 部署蓝环境

[root@master231 blue-green]# cat 01-blue.yaml 
kind: Deployment
apiVersion: apps/v1
metadata:name: liux-blue
spec:replicas: 3selector:matchLabels:app: bluetemplate:metadata:labels:app: bluespec:containers:- name: v1image: harbor.liux.com/liux-apps/apps:v1---kind: Service
apiVersion: v1
metadata:name: liux-app-svc
spec:type: NodePortports:- port: 80targetPort: 80nodePort: 30080selector:app: blue
[root@master231 blue-green]# 
[root@master231 blue-green]#  kubectl apply -f 01-blue.yaml 
deployment.apps/liux-blue created
service/liux-app-svc created
[root@master231 blue-green]#
#测试访问
[root@master231 blue-green]# while true ; do sleep 0.5;curl 10.0.0.233:30080; done

4.2 部署绿环境

[root@master231 blue-green]# cat 02-green.yaml 
kind: Deployment
apiVersion: apps/v1
metadata:name: liux-green
spec:replicas: 3selector:matchLabels:app: greentemplate:metadata:labels:app: greenspec:containers:- name: mywebimage: harbor.liux.com/liux-apps/apps:v2
[root@master231 blue-green]# 
[root@master231 blue-green]#  kubectl apply -f 02-green.yaml 
deployment.apps/liux-green created

4.4 切换svc的标签

[root@master231 blue-green]# cat 03-switch-svc-selector.yaml 
kind: Service
apiVersion: v1
metadata:name: liux-app-svc
spec:type: NodePortports:- port: 80targetPort: 80nodePort: 30080selector:# app: blueapp: green
[root@master231 blue-green]# 
[root@master231 blue-green]# kubectl apply -f 03-switch-svc-selector.yaml 
service/liux-app-svc configured

5.Deployment灰度发布

5.1 部署旧版本

先将副本数设置为3，随着新版本的创建，将副本逐渐调低到0

[root@master231 canary-huidu]# cat 01-old.yaml 
kind: Deployment
apiVersion: apps/v1
metadata:name: liux-old
spec:replicas: 3selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: mywebimage: harbor.liux.com/liux-apps/apps:v1
---
kind: Service
apiVersion: v1
metadata:name: liux-web-svc
spec:type: NodePortports:- port: 80targetPort: 80nodePort: 30080selector:app: web
[root@master231 canary-huidu]# 
[root@master231 canary-huidu]# kubectl apply -f 01-old.yaml 
deployment.apps/liux-old created
service/liux-web-svc created

5.2 部署新版本

先将副本数设置为1，随着新版本的稳定，将副本逐渐调高到3

[root@master231 canary-huidu]# cat 02-new.yaml 
kind: Deployment
apiVersion: apps/v1
metadata:name: liux-new
spec:replicas: 1selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: mywebimage: harbor.liux.com/liux-apps/apps:v2
[root@master231 canary-huidu]# 
[root@master231 canary-huidu]# 
[root@master231 canary-huidu]# kubectl apply -f 02-new.yaml 
deployment.apps/liux-new created

5.3 修改副本数量以及测试结果

将旧的副本数量手动修改从3-0，与此同时，将新的副本数量从1-3

[root@master231 canary-huidu]# kubectl edit deploy liux-old 
deployment.apps/liux-old edited
[root@master231 canary-huidu]# kubectl edit deploy liux-new
deployment.apps/liux-new edited#测试访问
[root@master231 ~]# while true ; do sleep 0.5;curl  10.0.0.233:30080; done

三、service

1.概述

service 用于服务发现和负载均衡。基于labels标签关联后端pod列表，以实现后端节点得动态发现，从而管理endpoints资源；负载均衡，底层借助于kube-proxy组件实现，基于iptables或者ipvs将用户请求转发给不同的Pod以均衡流量。

Service配置Selector标签, Endpoints Controller(controller manager)会自动创建对应的endpoint对象,否则.不会生成endpoint对象。

2.service类型

ClusterIP（默认）：集群内部访问，自动分配一个仅 Cluster 内部可以访问的虚拟 IP；
NodePort：通过节点IP和端口暴露服务，在ClusterIP基础上为service在所有worker节点绑定一个端口，通过nodeport端口来访问服务；
LoadBalancer：集成云厂商的负载均衡器（如AWS ELB）；
ExternalName：映射到外部DNS。用于将K8S集群外部的服务映射至K8S集群内部访问，让集群内部的Pod能够通过固定的service名称访问集群外部的服务。

3.service示例

[root@master-1 nfs]# vim  nginx-demo.yaml
apiVersion: v1
kind: Service
metadata:labels:app: nginx-demoname: nginx-demo
spec:# 指定svc的类型为NodePort，也就是在默认的ClusterIP基础之上多监听所有worker节点的端口而已。type: NodePort# 配置端口映射ports:- nodePort: 30698# 指定Service服务本身的端口号port: 88protocol: TCP# 后端Pod提供服务的端口号targetPort: 80# 基于标签选择器关联Podselector:app: nginx-demo[root@master-1 nfs]# kubectl  apply -f nginx-demo.yaml
[root@master-1 nfs]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.0.0.1     <none>        443/TCP        16d
nginx-demo   NodePort    10.0.0.187   <none>        88:30698/TCP   2d
[root@master-1 nfs]#  kubectl get endpoints
NAME             ENDPOINTS                                                  AGE
nginx-demo       172.17.1.3:80,172.17.77.11:80                              2d1h[root@master-1 nfs]# kubectl describe svc nginx-demo
Name:                     nginx-demo
Namespace:                default
Labels:                   app=nginx-demo
Annotations:              <none>
Selector:                 app=nginx-demo
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.0.0.187
IPs:                      10.0.0.187
Port:                     <unset>  88/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30698/TCP
Endpoints:                172.17.1.3:80,172.17.77.11:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>#访问
http://192.168.91.22:30698

4.endpoints

Endpoint是Kubernetes集群中的一个资源对象,存储在etcd中,用来记录一个Service对应的所有pod的访问地址.

Service配置Selector, 创建service时Endpoints Controller(controller manager)会自动创建对应的endpoint对象,否则.不会生成endpoint对象.

#查看endpoints
[root@master-1 nfs]#  kubectl get endpoints
NAME             ENDPOINTS                                                  AGE
fuseim.pri-ifs   <none>                                                     13d
kubernetes       192.168.91.18:6443,192.168.91.19:6443,192.168.91.20:6443   16d
nginx-demo       172.17.1.3:80,172.17.77.11:80                              2d1h
#查看etcd数据
[root@master-1 nfs]#  export ETCDCTL_API=3
[root@master-1 nfs]# export ETCD_ENDPOINTS=http://192.168.91.19:2390
[root@master-1 nfs]# etcdctl --endpoints=${ETCD_ENDPOINTS} get / --prefix --keys-only | grep 'endpoints/default/nginx-demo'
/registry/services/endpoints/default/nginx-demo

四、Ingress

1.概念

Ingress是k8s中管理外部流量的核心组件，通过灵活的路由规则和丰富的控制器生态满足多样化需求。

k8s使用ingress和ingress controller两者结合实现了完整的ingress负载均衡器。负载分发时，ingress controller基于ingress规则将请求转发到service对应的endpoint上，用于将不同URL的访问请求转发到后端不同的service，以实现http层的业务路由机制。

全过程：ingress controller-->ingress规则-->services-->endpoints(pod)

2.示例编写ingress规则

访问nginx.liux.com，将会代理到svc中名称nginx.liux.com端口88上去
[root@master-1 ingress]# cat nginx-route-https.yaml 
#注意命名空间 namespace与要代理的服务需要在同一个名称空间
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:name: nginx-routenamespace: kube-system
spec:entryPoints:- webroutes:- match: Host(`nginx.liux.com`)kind: Ruleservices:- name: nginx-demoport: 88

3.Ingress与service的区别

在 K8s 中，Ingress 和 Service 都是用于管理网络流量的核心组件，但它们的职责和使用场景有显著区别。

Service 是基础网络抽象，确保 Pod 的可访问性。
Ingress 是高级流量网关，专注于 HTTP 路由和集中管理。
两者通常结合使用：Ingress 处理外部请求的路由，Service 负责内部流量的分发。

特性	Service	Ingress
层级	L4（TCP/UDP）	L7（HTTP/HTTPS
核心功能	服务发现、基础负载均衡	高级路由、SSL 终止、流量管理
外部暴露方式	NodePort、LoadBalancer	通过 Ingress Controller + 规则
路由规则	仅 IP/端口	域名、路径、请求头等
资源成本	每个 LoadBalancer 独立实例	单一入口点管理多个服务
依赖组件	无需额外组件	需要 Ingress Controller

示例：一个 Web 应用服务包含frontend-service（前端）和backend-service（后端 API），可进行如下配置：

配置方式：

Service：为 frontend-service 和 backend-service 创建 ClusterIP 类型的 Service，供集群内访问。
Ingress：定义规则将 www.example.com/ 路由到 frontend-service，将 www.example.com/api 路由到 backend-service，并启用 HTTPS。

这样外部用户通过统一的域名访问，而 Ingress 根据路径将请求分发到不同的 Service，再由 Service 负载均衡到具体的 Pod。

五. ConfigMap 和 Secret

ConfigMap 和 Secret 都是用于管理应用配置的核心资源，但它们的用途和安全性有显著区别。

1. ConfigMap

作用：

存储非敏感的配置数据（如环境变量、配置文件、命令行参数等
将配置与容器镜像解耦，便于应用配置的灵活管理

数据格式：

数据以明文形式存储（如键值对、JSON、YAML 或纯文本文件）

典型场景：

存储应用的配置文件（如 nginx.conf、application.properties）。
定义环境变量（如 LOG_LEVEL=debug）。
共享配置给多个 Pod 或多个容器。

安全性：

不加密，数据对集群内用户可见，不适合存储敏感信息。

使用方式：

通过环境变量注入容器。
挂载为卷（Volume）到 Pod 的文件系统中。

示例：

#编写cm资源
[root@master231 cm]#  cat 02-cm-games.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: nginx-conf
# 指定cm的数据
data:games.conf: |server {listen        0.0.0.0:99;root          /usr/local/nginx/html/bird/;server_name   game01.liux.com;}#编写pod资源清单（在此引用cm资源）
[root@master231 pod]# vim 16-pods-volumes-configMap-games.yaml
apiVersion: v1
kind: Pod
metadata:name: liux-games-cm-008
spec:nodeName: worker233# hostNetwork: truevolumes:- name: data01# 指定存储卷类型是configMapconfigMap:# 指定configMap的名称name: nginx-conf# 引用configMap中的某个key，若不指定，则引用configMap资源的所有key。#items:# 指定configMap的key#- key: student.info# 暂时理解为在容器挂载点的文件名称。#path: banzhan.infocontainers:- name: gamesimage: harbor.liux.com/liux-games/games:v0.5volumeMounts:- name: data01#mountPath: /liux-linux86mountPath: /etc/nginx/conf.d/

2.Secret

作用：

存储敏感信息（如密码、API 密钥、TLS 证书、SSH 密钥等）。
提供一定程度的安全保护（非完全加密，需结合其他机制增强安全性）。

数据格式：

数据以 Base64 编码形式存储（非加密，仅防意外泄露）。
支持 stringData 字段直接写入明文（自动转换为 Base64）。

典型场景：

存储数据库密码（如 mysql-password）。
存储 TLS 证书（如 tls.crt 和 tls.key）。
容器镜像仓库的认证信息（如 Docker harbor 凭据）。

安全性：

Base64 编码仅防止明文暴露，仍需配合以下措施
启用 Kubernetes 的 Secret 加密机制（如使用 KMS、Vault）。
限制集群内 RBAC 权限（避免未授权访问）。

使用方式：

通过环境变量注入容器（不推荐，可能被日志记录）。
挂载为卷到 Pod 的文件系统中（更安全）。

示例一创建：

#1.声明式创建
[root@master231 secrets]# echo admin |base64
YWRtaW4K
[root@master231 secrets]# echo 12366 |base64
MTIzNjYK
[root@master231 secrets]# vim 01-secret-userinfo.yaml apiVersion: v1
kind: Secret
metadata:name: my-secrets-01
data:# 对于Secret的值进行base64编码，当Pod的容器使用secret时会自动对数据进行解码username: YWRtaW4Kpassword: MTIzNjYK
[root@master231 secrets]# kubectl apply -f 01-secret-userinfo.yaml 
secret/my-secrets-01 created
[root@master231 secrets]# kubectl get secrets
NAME                                 TYPE                                  DATA   AGE
my-secrets-01                        Opaque                                2      82s#2. 响应式创建# - 基于命令行key=value的方式创建
[root@master231 secrets]# kubectl create secret generic my-secrets-02 --from-literal=username='admin' --from-literal=password='12366'# - 基于命令行读取文件的方式创建
[root@master231 secrets]# ssh-keygen -t rsa -f ~/.ssh/id_rsa -P '' -q
[root@master231 secrets]# kubectl create secret generic my-secrets-03 --from-file=ssh-privatekey=/root/.ssh/id_rsa --from-file=ssh-publickey=/root/.ssh/id_rsa.pub #响应式创建harbor的认证信息
[root@master231 secrets]#  kubectl create secret docker-registry liux-harbor --docker-username=admin --docker-password=12366 --docker-email=admin@liux.com --docker-server=harbor.liux.com

示例二引用：

#3.在pod中引用  基于存储卷、环境变量的方式挂载[root@master231 pod]# cat 31-pods-secrets-env-volumes.yaml 
apiVersion: v1
kind: Pod
metadata:name: linux86-web-secrets-env-cm-001
spec:volumes:- name: data01# 指定存储卷类型为secretsecret:# 指定secret的名称secretName: my-secrets-01- name: data02secret:secretName: my-secrets-01items:- key: usernamepath: username.info- key: passwordpath: password.txtcontainers:- name: webimage: harbor.liux.com/liux-web/nginx:1.25.1-alpine#基于存储卷的方式挂载volumeMounts:- name: data01mountPath: /liux-linux86-secrets- name: data02mountPath: /liux-linux86-secrets-2#基于环境变量的方式挂载env:- name: liux_USERNAMEvalueFrom:# 值引用自某个secretsecretKeyRef:# 指定secret的名称name: my-secrets-01# 指定引用secret对应的keykey: username- name: liux_SSH_PRIVATEKEYvalueFrom:secretKeyRef:name: my-secrets-03key: ssh-privatekey
[root@master231 pod]# 
[root@master231 pod]# kubectl apply -f 31-pods-secrets-env-volumes.yaml 
pod/linux86-web-secrets-env-cm-001 created
[root@master231 pod]# kubectl get pods
NAME                               READY   STATUS        RESTARTS      AGE
linux86-web-secrets-env-cm-001     1/1     Running       0             8s
[root@master231 pod]# kubectl exec -it linux86-web-secrets-env-cm-001 -- env#在pod中引用harbor登录信息 注意，请确保你创建的用户必须在harbor中对相应的项目有访问权限！
[root@master231 pod]# cat 32-pods-harbor-secrets.yaml 
apiVersion: v1
kind: Pod
metadata:name: linux86-secrets-harbor-001
spec:# 指定harbor的secret认证信息，可以指定多个。imagePullSecrets:- name: harbor-liuxing# - name: liux-harborcontainers:- name: webimage: harbor.liux.com/liux-apps/apps:v1# 指定镜像的拉取策略，若不指定，当tag为latest时，默认是Always，当tag非latest时，则默认策略为IfNotPresentimagePullPolicy: Always# imagePullPolicy: IfNotPresent

3.总结

特性	ConfigMap	Secret
数据类型	非敏感配置（明文）	敏感信息（Base64 编码）
安全性	无加密，明文存储	Base64 编码（非加密），需额外安全措施
典型用途	配置文件、环境变量、命令行参数	密码、密钥、证书
存储限制	无大小限制	每个 Secret 最大 1MiB
更新与热加载	支持更新，挂载为卷时可自动同步	同 ConfigMap，但需注意敏感数据更新策略

k8s核心资源对象一（入门到精通）

一、pod

1 pod概念

2 pod示例

二、deployment

1 介绍

2 更新策略

3 Deployment滚动发布

4.Deloyment蓝绿发布

4.1 部署蓝环境

4.2 部署绿环境

4.4 切换svc的标签

5.Deployment灰度发布

5.1 部署旧版本

5.2 部署新版本

5.3 修改副本数量以及测试结果

三、service

1.概述

2.service类型

3.service示例

4.endpoints

四、Ingress

1.概念

2.示例编写ingress规则

3.Ingress与service的区别

五. ConfigMap 和 Secret

1. ConfigMap

2.Secret

3.总结

相关资讯

热文排行

最新新闻

推荐新闻

热搜词

k8s核心资源对象一（入门到精通）

一、pod

1 pod概念

2 pod示例

二、deployment

1 介绍

2 更新策略

3 Deployment滚动发布

4.Deloyment蓝绿发布

4.1 部署蓝环境

4.2 部署绿环境

4.4 切换svc的标签

5.Deployment灰度发布

5.1 部署旧版本

5.2 部署新版本

5.3 修改副本数量以及测试结果

三、service

1.概述

2.service类型

3.service示例

4.endpoints

四、Ingress

1.概念

2.示例 编写ingress规则

3.Ingress与service的区别

五. ConfigMap 和 Secret

1. ConfigMap

2.Secret

3.总结

相关资讯

热文排行

最新新闻

推荐新闻

热搜词

2.示例编写ingress规则