1.kubectl命令的使用
kubectl是apiserverd的客户端工具,工作在命令行下,能够连接apiserver实现各种增删改查等操作,支可以使用kubectl -h查询支持哪些命令。
1.1 基本命令
kubectl version # 查看 kubectl 和集群的版本
kubectl cluster-info # 查看集群信息
kubectl get nodes # 查看所有节点
kubectl get pod # 查看所有 Pod
kubectl get svc # 查看所有服务
kubectl get deployments # 查看所有 Deployment
kubectl get all # 获取所有资源(Pod、Service、Deployment 等)
kubectl config view # 查看当前 kubeconfig 配置
kubectl config use-context <name> # 切换 K8s 集群环境
1.2 Pod 操作
kubectl get pods -o wide # 查看 Pod 详细信息
kubectl describe pod <pod_name> # 查看 Pod 详情
kubectl logs <pod_name> # 查看 Pod 日志
kubectl logs -f <pod_name> # 实时查看 Pod 日志
kubectl logs <pod_name> -c <container_name> # 指定容器查看日志(多容器 Pod)
kubectl exec -it <pod_name> -- /bin/sh # 进入 Pod(alpine, busybox)
kubectl exec -it <pod_name> -- /bin/bash # 进入 Pod(常见 Linux 发行版)
kubectl delete pod <pod_name> # 删除 Pod
kubectl delete pod --all # 删除所有 Pod
kubectl get pod --field-selector=status.phase=Running # 查询运行中的 Pod
1.3 Namespace(命名空间)
kubectl get namespaces # 查看所有命名空间
kubectl create namespace <name> # 创建命名空间
kubectl delete namespace <name> # 删除命名空间
kubectl get pods -n <namespace> # 查看指定命名空间的 Pod
kubectl config set-context --current --namespace=<name> # 切换默认命名空间
1.4 Deployment 操作
kubectl create deployment <name> --image=<image> # 创建 Deployment
kubectl get deployments # 查看所有 Deployment
kubectl describe deployment <name> # 查看 Deployment 详情
kubectl scale deployment <name> --replicas=<num> # 扩缩容
kubectl delete deployment <name> # 删除 Deployment
kubectl rollout status deployment <name> # 查看滚动更新状态
kubectl rollout undo deployment <name> # 回滚 Deployment
1.5 Service(服务)操作
kubectl expose deployment <name> --type=NodePort --port=80 # 创建 Service
kubectl get services # 查看所有 Service
kubectl describe service <name> # 查看 Service 详情
kubectl delete service <name> # 删除 Service
1.6 YAML 文件管理
kubectl apply -f <file>.yaml # 通过 YAML 文件创建资源
kubectl delete -f <file>.yaml # 通过 YAML 文件删除资源
kubectl get -f <file>.yaml # 通过 YAML 查询资源
kubectl edit -f <file>.yaml # 在线编辑 YAML 文件
1.7 其他命令
kubectl top node # 查看节点资源使用情况
kubectl top pod # 查看 Pod 资源使用情况
kubectl cp <pod>:<file> <local> # 从 Pod 拷贝文件到本地
kubectl cp <local> <pod>:<file> # 从本地拷贝文件到 Pod
kubectl port-forward <pod> 8080:80 # 端口转发(本地 8080 -> Pod 80)
kubectl drain <node> --ignore-daemonsets # 驱逐节点上的 Pod
kubectl cordon <node> # 标记节点为不可调度
kubectl uncordon <node> # 取消不可调度
kubectl taint nodes <node> key=value:NoSchedule # 给节点添加污点
kubectl get events --sort-by=.metadata.creationTimestamp # 查看最新事件
2.Namespase
Namespace(命名空间) ,它是 Kubernetes 中用于资源隔离和分组管理的核心概念。它能够将同一集群中的资源划分为相互隔离的组。同一个命名空间内的资源名称唯一,它是用来隔离资源的,不隔离网络。
kubernets启动时会创建四个初始命名空间:
- default
kubernets包含命名空间,便于用户无需创建命名空间即可开始使用新集群,如果不指定命名空间,默认操作都是在这个命名空间下。 - kube-node-lease
用于存放节点租约(Node Lease)对象,优化节点心跳检测机制。每个节点会定期更新其租约对象,以表明节点存活状态。 - kube-system
存放 Kubernetes 自身的核心系统组件,例如 kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy、CoreDNS 等。 kube-public
存放集群范围内的公共信息,例如某些需要全局访问的配置或引导数据。默认情况下此命名空间是公开可读的(所有用户均可访问)。2.1 Namespace基本操作
#查看命名空间,namespace可以简写为ns kubectl get namespace
#创建命名空间 #命令行方式 #kubectl create namespace 命名空间 kubectl create namespace longyaowei
#yaml方式 #新建一个ns.yaml的yaml文件,并写入下列内容 apiVersion: v1 kind: Namespace metadata: name: longyaowei #然后执行: kubectl create -f ns.yaml
#删除命名空间 kubectl delete ns 命名空间 kubectl delete ns longyaowei
3.Pod
在 Kubernetes 中,Pod 是集群中可以创建和管理的最小单位。每个 Pod 代表一个容器化应用的运行实例,可以包含一个或多个容器(就像一个豌豆荚一样)。Pod 的主要作用是为这些容器提供共享的资源和运行环境。
#创建pod:运行一个nginx容器 #命令行方式 #kubectl run pod名称 --image=容器:版本 kubectl run mynginx --image=nginx:latest #获取pod信息,-o wide 表示更详细的显示信息 -n 命名空间 查询对应的namespace下的pod
#创建到指定命名空间下 #kubectl run pod名称 --image=容器:版本 -n 命名空间 kubectl run mynginx --image=nginx:latest -n longyaowei
#yaml方式 #新建一个mynginx01.yaml的yaml文件,并写入下列内容 apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx:latest ports: - containerPort: 80 #然后执行: kubectl create -f mynginx01.yaml
上面演示的都是一个pod运行一个容器,那pod是否可以运行多个容器呢?答案是可以的,刚刚有提到,pod就像一个豌豆荚,可以包含一个或多个容器。#yaml方式 #新建一个mypod.yaml的yaml文件,并写入下列内容 apiVersion: v1 kind: Pod metadata: name: web-server spec: containers: #第一个容器:Nginx - name: nginx-container image: nginx:latest # 第二个容器:Tomcat - name: tomcat-container image: tomcat:latest #然后执行: kubectl apply -f mypod.yaml
思考:细心的朋友应该看出来了,为什么我创建pod有时用create,有时用apply呢?
(1)核心区别:
(2)使用场景详解:
kubectl create- 用途:
从零开始创建新资源,若资源已存在则报错(AlreadyExists)。 适用场景:
快速创建一次性资源(如临时测试)。
在脚本中明确要求资源必须不存在时才创建。
示例:# 从 YAML 文件创建资源(若存在则失败) kubectl create -f pod.yaml # 直接通过命令创建资源(无需配置文件) kubectl create deployment nginx --image=nginx:latest
kubectl apply
- 用途:
根据配置文件(YAML/JSON)声明资源的期望状态。若资源不存在则创建,若存在则更新。 适用场景:
持续维护资源的配置(如生产环境的滚动更新)。
结合版本控制(Git)实现 GitOps 工作流。
示例:# 应用配置文件(创建或更新资源) kubectl apply -f deployment.yaml # 查看资源的历史配置差异 kubectl diff -f deployment.yaml
(3)底层机制
kubectl create
直接向 Kubernetes API 发送 CREATE 请求。
不保留配置的元数据,无法追溯历史配置变更。
kubectl apply
向 API 发送 PATCH 请求,计算当前状态与期望状态的差异后更新资源。
记录最后一次应用的配置(通过注解 kubectl.kubernetes.io/last-applied-configuration),便于后续更新时对比变更。
支持三路合并策略(Three-Way Merge):对比当前配置、已记录的配置和新的配置,解决冲突。
(4)示例对比:#使用kubectl create # 第一次创建 kubectl create -f deployment.yaml # 修改 deployment.yaml 后再次运行(报错:资源已存在) kubectl create -f deployment.yaml # Error: deployments.apps "nginx" already exists
#使用kubectl apply # 第一次创建 kubectl apply -f deployment.yaml # 修改 deployment.yaml 后再次运行(自动更新) kubectl apply -f deployment.yaml # 输出 deployment.apps/nginx configured
(5)如何选择?
推荐优先使用 apply :
声明式管理更符合 Kubernetes 的设计哲学,适合长期维护资源状态,尤其在生产环境中。
使用 create 的场景:
明确需要强制创建新资源(例如确保资源不存在时初始化),或在脚本中快速生成资源。
回到刚刚的使用yaml在一个pod创建多个容器
可以使用kubectl describe pod web-server查看web-server详细信息
[root@k8s-master k8s-deame]# kubectl describe pod web-server
Name: web-server
Namespace: default
Priority: 0
Node: node2/10.10.2.133
Start Time: Sun, 06 Apr 2025 16:32:37 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 172.20.2.37
IPs:
IP: 172.20.2.37
Containers:
nginx-container:
Container ID: docker://ec27a93e15a11dbf0cbc51c3c4f345a78d75d1468f462a4c2b5a941deac783c4
Image: nginx:latest
Image ID: docker-pullable://nginx@sha256:124b44bfc9ccd1f3cedf4b592d4d1e8bddb78b51ec2ed5056c52d3692baebc19
Port: <none>
Host Port: <none>
State: Running
Started: Sun, 06 Apr 2025 16:32:48 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6f6pt (ro)
tomcat-container:
Container ID: docker://d1325be9ccf58cf6c0ae4c0fd2f33f5bfe1a4af86e6cb1322c8dd14533162997
Image: tomcat:latest
Image ID: docker-pullable://tomcat@sha256:1374a565d5122fdb42807f3a5f2d4fcc245a5e15420ff5bb5123afedc8ef769d
Port: <none>
Host Port: <none>
State: Running
Started: Sun, 06 Apr 2025 16:32:50 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6f6pt (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-6f6pt:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 104s default-scheduler Successfully assigned default/web-server to node2
Normal Pulling 98s kubelet Pulling image "nginx:latest"
Normal Pulled 87s kubelet Successfully pulled image "nginx:latest" in 10.216670849s (10.216695843s including waiting)
Normal Created 87s kubelet Created container nginx-container
Normal Started 87s kubelet Started container nginx-container
Normal Pulling 87s kubelet Pulling image "tomcat:latest"
Normal Pulled 85s kubelet Successfully pulled image "tomcat:latest" in 2.242880782s (2.242886313s including waiting)
Normal Created 85s kubelet Created container tomcat-container
Normal Started 85s kubelet Started container tomcat-container
确实看到两个容器创建成功了,那怎么验证呢?
可以使用curl或者浏览器来验证
熟悉docker的朋友还可以进入到容器内部修改对应容器的配置来实现自己的个性化
4.Deployment
Deployment是一种用于管理应用部署的核心资源对象,它的核心作用是声明式地定义和管理 Pod 的副本集(ReplicaSet) ,实现应用的滚动更新、版本回滚、扩缩容等功能。
常用控制器比对:
后续再详细介绍这几个控制器,这次重点介绍Deployment的用法
4.1副本管理(Pod 高可用性)
作用:
确保指定数量的 Pod 副本(Replicas)始终处于运行状态。当 Pod 因节点故障或手动删除而终止时,Deployment 会自动创建新的 Pod 替换。
之前在第三节演示的创建pod都是只有一个副本,而且没有自愈能力。想要拥有多副本和自愈能力,那么就要用到副本管理工具了。#命令行方式 kubectl create deployment mynginx --image=nginx:1.20 --replicas=3
#yaml方式 #使用yaml文件创建一个始终维持3个副本的pod #新建一个mynginx.yaml文件,并写入下列内容 apiVersion: apps/v1 kind: Deployment metadata: name: mynginx namespace: default spec: replicas: 3 selector: matchLabels: app: mynginx template: metadata: labels: app: mynginx spec: containers: - name: mynginx image: nginx:1.20 ports: - containerPort: 80 #然后执行: kubectl apply -f mynginx.yaml
验证:4.2.滚动更新(Rolling Update)
- 作用:
逐步用新版本的 Pod 替换旧版本,确保应用在更新过程中始终可用(零停机时间)。 - 机制:
创建新的 ReplicaSet(新版本 Pod 模板)。
逐步增加新 Pod 数量,同时减少旧 Pod 数量。 触发条件:
修改 Pod 模板(如更新镜像版本、环境变量等)。#将nginx版本从1.20更新到1.21 #命令行更新方式: kubectl set image deployment mynginx mynginx=nginx:1.21 --record
#查看历史版本 kubectl rollout history deployment mynginx
#回滚到指定版本 kubectl rollout undo deployment mynginx --to-revision=2
4.3扩缩容
#命令行扩缩容方式:
#扩容到10个副本
kubectl scale deployment/mynginx --replicas=10
#缩减到3个副本
kubectl scale deployment/mynginx --replicas=3
#修改yaml文件方式
#vim mynginx.yaml
#修改副本数量replicas:副本数
#然后执行
kubectl describe deployment mynginx
#还可以使用kubectl edit在线更新(修改后立马生效)
kubectl edit deployment mynginx
5.Service
Service 是一种核心资源对象,用于将一组 Pod 暴露给网络,提供稳定的访问入口、负载均衡和服务发现功能。它是 Kubernetes 中实现微服务架构的关键组件。
5.1 Service 的核心作用
- 服务发现
Service 为动态变化的 Pod 提供一个固定的访问入口(如 DNS 名称或 IP 地址),避免直接依赖 Pod 的不稳定 IP。 - 负载均衡
将流量自动分发到后端的多个 Pod,确保请求的高可用性和性能。 - 抽象后端
解耦前端应用和后端 Pod,即使 Pod 发生扩缩容或重启,前端也无需感知变化。 Service 的工作原理
(1)标签选择器(Label Selector)
Service 通过标签(Labels)关联到一组 Pod。例如,选择所有带有 app=web 标签的 Pod。
(2)Endpoints
Service 会自动维护一个 Endpoints 列表(即后端 Pod 的 IP 地址列表),流量会被转发到这些 Pod。
(3)代理机制
Kubernetes 通过 kube-proxy 组件实现流量转发,支持 iptables 或 IPVS 模式。5.2 Service 的常见类型
Service 的配置示例ClusterIP 类型
apiVersion: v1 kind: Service metadata: name: web-service spec: type: ClusterIP selector: app: web # 选择标签为 app=web 的 Pod ports: - protocol: TCP port: 80 # Service 的端口 targetPort: 80 # Pod 的端口
NodePort 类型
apiVersion: v1 kind: Service metadata: name: web-nodeport spec: type: NodePort selector: app: web ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 31000 # 手动指定节点端口(可选)
5.3 Service 的访问方式
(1)集群内部访问
通过 DNS 名称:<service-name>.<namespace>.svc.cluster.local
例如:web-service.default.svc.cluster.local
简化 DNS:同一命名空间下可直接用 web-service:80。
(2)集群外部访问
NodePort:通过 节点IP:节点端口(如 192.168.1.100:31000)。
LoadBalancer:通过云厂商提供的外部 IP(如 http://35.200.100.1:80)。
Service VS Ingress5.4创建service
#命令行方式 kubectl expose deployment mynginx --name=mynginx --port=80 --type=NodePort
#yaml方式 #编辑yaml文件nginx_svc.yaml apiVersion: v1 kind: Service metadata: name: mynginx spec: ports: - nodePort: 30680 #service在宿主机上映射的外网访问端口,端口范围必须在30000-32767之间 port: 80 #service的虚拟IP对应的端口,在集群内网可以访问用service的IP加端口号访问服务 protocol: TCP targetPort: 80 #pod暴露的端口,一般与pod内部容器暴露的一致 selector: app: mynginx type: NodePort #然后执行: kubectl apply -f nginx_svc.yaml
测试:
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。