kubernetes基础
yaml文件应用于 Kubernetes 集群以创建 Pod
#Kubernetes 将按照定义创建 Pod
kubectl apply -f nginx-pod.yaml
--dry-run=client 标志来模拟应用清单，而无需实际对集群进行更改。
kubectl apply -f web-app.yaml --dry-run=client
kubectl apply -f web-app.yaml -v=7
#-v 标志后跟详细级别,更详细的输出
获取更详细的信息
kubectl get deployments -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx-deployment 3/3 3 3 4m58s nginx nginx:latest app=nginx
redis-master 1/1 1 1 108s master registry.k8s.io/redis:e2e app=redis,role=master,tier=backend
web-app 2/2 2 2 2m7s web nginx:alpine app=web
| 字段 | 含义 | 示例值 | 说明 |
|---|---|---|---|
| NAME | Deployment 的名字 | nginx-deployment | 区分不同 Deployment |
| READY | 当前就绪 Pod 数 / 期望 Pod 数 | 3/3 | 有 3 个 Pod，全部处于 Ready 状态 |
| UP-TO-DATE | 已经更新到最新模板的 Pod 数量 | 3 | 表示 3 个 Pod 都是最新版本 |
| AVAILABLE | 可以对外提供服务的 Pod 数量 | 3 | 与 READY 一般相同，但更新时可能不一致 |
| AGE | Deployment 运行时长 | 4m58s | 从创建到现在的时间 |
| CONTAINERS | Pod 内容器的名称 | nginx | Deployment 模板中定义的容器名 |
| IMAGES | 容器镜像名称及版本 | nginx:latest | 运行容器的镜像 |
| SELECTOR | Label 选择器 | app=nginx | 用来匹配和管理 Pod 的标签 |
列出所有服务
kubectl get services
kubectl describe service web-service
Name: web-service
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=web
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.98.89.54
IPs: 10.98.89.54
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.0.8:80,10.244.0.9:80
Session Affinity: None
Events: <none>
| 字段 | 含义 | 示例值 | 说明 |
|---|---|---|---|
| Name | Service 名称 | web-service | Service 的标识符 |
| Namespace | 命名空间 | default | Service 所在的命名空间 |
| Labels | 标签 | app=web | 用于筛选和组织资源 |
| Annotations | 注解 | kubectl.kubernetes.io/last-applied-configuration: {...} | 附加的元数据信息，供工具或运维使用 |
| Selector | Pod 选择器 | app=web | Service 通过这些 label 找到对应的 Pod |
| Type | Service 类型 | ClusterIP / NodePort / LoadBalancer | 决定 Service 如何暴露 |
| IP (ClusterIP) | Service 的虚拟 IP | 10.96.152.34 | 集群内访问 Service 的入口 |
| IP Family Policy / IP Families | 支持的 IP 协议族 | SingleStack / IPv4 | IPv4 或 IPv6 配置 |
| Port(s) | 端口映射规则 | 80/TCP → 8080 | Service 端口与 Pod 端口的映射 |
| TargetPort | Pod 内部端口 | 8080/TCP | Pod 实际监听的端口 |
| Endpoints | Service 实际后端 Pod 的 IP:Port |
| 检查服务是否具有端点，并且它们是否与正在运行的 Pod 的 IP 地址相对应。如果没有端点，请对服务的选择器和容器标签进行故障排除。 |
| Session Affinity | 会话亲和性 | None / ClientIP | 是否将同一客户端的请求固定到同一 Pod |
| Events | 与 Service 相关的事件 | Normal EnsuredLoadBalancer | 用于排查问题的事件信息 |
启动kubectl proxy
kubectl proxy --port=8080 &
使用 jobs 命令列出后台进程
停止kubectl proxy
#[1] Running kubectl proxy --port=8080
kill %1
出于安全原因，kubectl proxy只能在本地主机 （127.0.0.1） 上访问。它不用于公开服务。
部署 Pod，选择特定的 Pod
# Get a Pod name from the deployment
POD_NAME=$(kubectl get pods -l app=nginx | grep nginx-deployment | head -n 1 | awk '{print $1}')
# Run commands in the deployment's Pod
kubectl exec -it $POD_NAME -- /bin/bash
描述 Pod 以获取更多详细信息：
kubectl describe pods -l app=debug
kubectl logs <pod-name>
描述节点资源
kubectl describe nodes minikube
查看所有集群事件
kubectl get events
# Watch events in real-time
kubectl get events -w
# Get events sorted by timestamp
kubectl get events --sort-by='.metadata.creationTimestamp'
# Filter by event type
kubectl get events --field-selector type=Warning
# Filter by specific resource
kubectl get events --field-selector involvedObject.kind=Deployment
yaml文件
apiVersion: apps/v1 #指定 Kubernetes API 版本
kind: Deployment #定义资源类型（部署）
metadata: #为部署提供名称和标签
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 #设置 Pod 副本的数量
selector: #帮助部署管理正确的 Pod
matchLabels:
app: nginx
template: #定义 Pod 规范
metadata:
labels:
app: nginx
spec:
containers: #指定容器映像和端口
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
ClusterIP：仅限内部集群访问
NodePort：在每个节点的 IP 上的静态端口上公开服务
验证 Pod 上的当前标签
kubectl get pods --show-labels
使用特定标签选择容器：
kubectl get pods -l app=nginx
#向其中一个 Pod 添加自定义标签
kubectl label pods nginx-deployment-xxx-yyy environment=development
#从容器中移除标签
kubectl label pods nginx-deployment-xxx-yyy environment-
删除服务
# Delete multiple services at once
kubectl delete service nginx-clusterip-service nginx-nodeport-service
Ingress
Ingress 是一个 API 对象，用于管理对 Kubernetes 集群中服务（通常是 HTTP）的外部访问。Ingress 提供：
负载均衡 ：将流量分配给多个后端服务
SSL/TLS 终止 ：处理安全连接
基于名称的虚拟主机 ：根据主机名将请求路由到不同的服务
基于路径的路由 ：根据 URL 路径将请求路由到不同的服务
Ingress 由两个组件组成：
Ingress Resource：定义路由规则的 Kubernetes API 对象
Ingress Controller：强制执行 Ingress 资源中定义的规则的实现
在 Minikube 中启用 Ingress 插件
minikube addons enable ingress
创建部署
kubectl create deployment web1 --image=nginx:alpine
kubectl create deployment web2 --image=httpd:alpine
这些部署公开为服务
kubectl expose deployment web1 --port=80 --type=ClusterIP --name=web1-service
kubectl expose deployment web2 --port=80 --type=ClusterIP --name=web2-service
Ingress 配置示例：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations: #Ingress 控制器的特定配置
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules: #定义流量如何路由到服务
- http:
paths:
- path: /web1 #将匹配的网址路径
pathType: Prefix #路径应如何匹配（Prefix、Exact 或 ImplementationSpecific）
backend:
service: #路由到特定的服务器和端口
name: web1-service
port:
number: 80
- path: /web2
pathType: Prefix
backend:
service:
name: web2-service
port:
number: 80
Kubernetes 通过增加 pod 实例（副本）数量，轻松扩展应用规模。
修改yaml文件中的replicas: 3
使用 kubectl scale
假如部署了 nginx-deployment
kubectl scale deployment nginx-deployment --replicas=4
创建一个临时pod测试负载均衡：
kubectl run curl-test --image=curlimages/curl --rm -it -- sh
离开：exit
ClusterIP 服务类型提供内部负载均衡。
水平舱自动扩展器（HPA）
能 根据负载自动增加或减少 Pod 数量，维持应用的性能与资源利用率。
启用 metrics 服务器插件,对HPA 的正常运行至关重要。
minikube addons enable metrics-server
配置文件中有kind: HorizontalPodAutoscaler，表示这是一个 HPA 对象。
示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
cubectl get hpa
打开load generator
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
另外一个终端验证，随着 HPA 规模的扩大，pods被新建
kubectl get pods -w
rollout 命令
| 命令 | 作用 |
|---|---|
| kubectl rollout status deployment web-app | 查看 Deployment 的滚动更新（Rollout）状态 |
kubectl rollout history deployment web-app | 查看历史版本 |
kubectl rollout undo deployment web-app | 回滚至上一个版本 |
kubectl rollout pause deployment web-app | 暂停滚动更新 |
kubectl rollout resume deployment web-app | 恢复更新 |
// 查看 image version
kubectl get pods -l app=web -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
kubectl set image deployment/web-app-custom-rollout nginx=nginx:1.25.0-alpine
// 把 Deployment 中名为 nginx 的容器的镜像更新成 nginx:1.25.0-alpine，并触发滚动更新。
常用命令：
kubectl get services // 查看服务
kubectl describe deployment nginx-deployment //查看部署信息
kubectl describe pods -l app=nginx //每个pods的详细信息
kubectl get events// 查看集群范围的事件
kubectl get events --field-selector involvedObject.kind=Deployment // 筛选Deployment相关的事件
kubectl wait --for=condition=Ready pod -l app=nginx # 等待标签为 app=nginx 的 Pod 变为就绪状态
kubectl logs -f nginx-busybox # 实时查看名为 nginx-busybox 的 Pod 的日志输出
kubectl exec -it nginx-busybox -c nginx -- /bin/sh # 进入名为 nginx-busybox 的 Pod 的 nginx 容器的交互式 shell
kubectl get deployment hello-world -o jsonpath='{.spec.template.spec.containers[0].image}' # 获取名为 hello-world 的部署中第一个容器的镜像名称
kubectl label deployment hello-world environment=development # 为名为 hello-world 的部署添加标签
kubectl get deployment hello-world --show-labels # 显示名为 hello-world 的部署及其标签
kubectl annotate deployment hello-world owner=team-alpha # 为名为 hello-world 的部署添加注释 owner=team-alpha
Kubernetes RBAC中的三个核心概念：
-
Role：定义了一组权限规则（例如，能对哪些资源做什么操作）。 -
RoleBinding：像一个“授权合同”，将某个Role或ClusterRole中定义的权限，授予一个或多个用户、组或服务账户。 -
ServiceAccount：Pod中运行的应用所使用的身份。
简单来说：Role 说明了“能干什么”，而 RoleBinding 说明了“谁可以这么干”。
ctr images ls与critcl images的区别
|
命令 |
作用 |
输出内容 |
是否依赖 CRI 配置 |
|
|
containerd 直接管理镜像 |
所有 containerd 存储的镜像 |
❌ 不依赖 CRI 配置 |
|
|
Kubernetes CRI 接口 |
Kubernetes 可用的镜像 |
✅ 依赖 crictl.yaml 或 runtime-endpoint |
(YAML 配置) ---> (ConfigMap) ---> (Pod)
写的资源文件 存配置 使用配置
PV（PersistentVolume）——运维配置的“真实存储”
PVC（PersistentVolumeClaim）——用户“申请一块盘”
-
Deployment / Pod 不直接用 PV
-
它们用 PVC 来申请需要的存储
Pod 是执行容器的单位；Job 是保证“某个任务一定跑完”的控制器。
Job 负责生成 Pod、监控 Pod、Pod 挂了就补 Pod，直到任务完成。
CronJob 就是 按固定时间自动运行 Job 的调度器
schedule: "*/5 * * * *" # 每 5 分钟执行一次
DaemonSet
DaemonSet 会确保集群中每个节点（或指定节点）上都运行一个 Pod。
StatefulSet
| 对比项 | Deployment | StatefulSet |
|---|---|---|
| Pod 身份 | 随机 | 固定（-0, -1） |
| 网络名 | 不稳定 | 稳定 DNS |
| 存储 | 共享或无 | 每 Pod 独立 PVC |
| 启停顺序 | 无序 | 有序 |
| 使用场景 | Web / API | DB / MQ / 存储 |
Deployment 管“副本数量”，StatefulSet 管“实例身份”
Secret
用来存储和向 Pod 安全地分发敏感数据（密码、Token、证书等）。
Secret 的几种常见类型：
type: Opaque // 最常用
type: kubernetes.io/dockerconfigjson //拉私有镜像
// 证书
type: kubernetes.io/tls
data:
tls.crt: <base64>
tls.key: <base64>
ResourceQuota
ResourceQuota 用来限制某个 namespace 能“最多用多少资源 + 创建多少对象”，防止一个团队或应用把集群资源用完。
示例：
资源总量
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
LimitRange
该功能用于设置 Kubernetes Pod 中的资源消耗限制，帮助管理分配给 Pod 的资源，防止资源争用问题。
示例：
apiVersion: v1
kind: LimitRange
metadata:
name: example-limitrange
spec:
limits:
- type: Container
max:
cpu: "1"
memory: "1Gi"
min:
cpu: "100m"
memory: "100Mi"
default:
cpu: "500m"
memory: "500Mi"
LimitRange作用于namespace，Pod 只要在这个 Namespace 里创建，就会被 LimitRange 约束
Pod 没写 resources → 注入默认值
Pod 写了 resources，但超出 LimitRange → 直接拒绝创建
Pod 写了 resources，在范围内 → 通过
ca.crt 与tls.crt
ca.crt / ca.key = 发证的人（CA）
tls.crt / tls.key = 被发的证（服务器或客户端）
CA 用 ca.key 给别人签 tls.crt
node affinity
节点亲和力用于调度符合特定条件的节点上的 pod。
示例：
apiVersion: v1
kind: Pod
metadata:
name: pod-with-node-affinity
spec:
containers:
- name: nginx
image: nginx:latest
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: type
operator: In # NotIn反亲和力
values:
- web
Liveness Probe与Readiness Probe
Liveness Probe（存活探针）用来判断容器是不是“还活着”。如果探测失败，kubelet 会直接重启容器，不管这个容器当前是不是还能对外提供服务。
程序卡死了 / 进入异常状态，但进程还在 → Liveness Probe 负责把它“拉起来重来一次”。
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
Readiness Probe（就绪探针）用来判断：这个 Pod 现在“能不能接收流量”。
-
作用：控制是否对外提供服务
-
失败后果：不接收流量（但容器继续运行）
-
恢复后果：自动重新加入 Service
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
关键参数：
| 参数 | 含义 |
|---|---|
initialDelaySeconds | 启动后多久开始检查 |
periodSeconds | 检查间隔 |
timeoutSeconds | 单次超时 |
failureThreshold | 连续失败多少次变 NotReady |
successThreshold | 连续成功多少次才恢复 Ready |
| 对比项 | Liveness Probe | Readiness Probe |
|---|---|---|
| 目的 | 是否需要重启容器 | 是否接收流量 |
| 失败后 | 重启容器 | 从 Service Endpoints 中摘除 |
| 是否杀进程 | 是 | 否 |
| 使用场景 | 程序卡死、自愈 | 启动慢、依赖未就绪 |
HorizontalPodAutoscaler
HorizontalPodAutoscaler（HPA） 是 Kubernetes 里用来做「水平自动伸缩 Pod 数量」的控制器。
它会根据设定的指标（CPU、内存、自定义指标等），自动调整某个 Deployment / StatefulSet / ReplicaSet 的副本数。
- 横向扩缩容：改的是 Pod 数量（replicas），不是 Pod 里的资源规格，也不是节点数。
- 核心目标：在负载高时自动加 Pod，负载低时自动减 Pod，减少人工调节和资源浪费。
metrics-server
metrics-server 是 Kubernetes 官方的“资源指标采集组件”，用于实时采集 Node / Pod 的 CPU、内存使用情况，并通过 Metrics API 提供给集群内的其他组件使用。
更多推荐
9
0- 0
已为社区贡献1条内容
所有评论(0)