1.1 管理操作分类
-
陈述式（命令式）管理方法 ：直接使用
kubectl命令。 -
声明式（配置清单式）管理方法 ：通过 YAML/JSON 文件定义资源状态。
1.2****陈述式资源管理方法
1.2.1****基本原理
1. Kubernetes 集群资源管理的唯一入口是通过调用 apiserver 的接口。
2. kubectl 是官方 CLI 命令行工具，用于与 apiserver 通信，将用户命令转化为 apiserver 能识别的
请求，实现集群资源管理。
- 查看 kubectl 命令大全：
kubectl --help
- 对资源的"增、删、查"操作较方便，但"改"操作相对复杂。
陈述式管理通过 kubectl 命令直接创建、查看、修改或删除资源，适合快速验证和交互式操作。
1.3 基础信息查看命令
bash
kubectl version # 查看版本信息
kubectl api-resources # 查看资源对象简写
kubectl cluster-info # 查看集群信息
bash
source <(kubectl completion bash) # 启用kubectl自动补全
journalctl -u kubelet -f # 查看node节点日志基本资源查看命令
kubectl get <resource> -o wide\|json\|yaml -n namespace
-n 指定命名空间
-o 指定输出格式
--all-namespaces ：显示所有命名空间
--show-labels ：显示所有标签
-l app=nginx ：筛选指定标签的资源
示例 ：
bash
kubectl get componentstatuses # 查看 master 节点状态
kubectl get namespace # 查看命名空间
kubectl get all -n default # 查看default命名空间的所有资源命名空间操作
bash
kubectl create ns app # 创建命名空间
kubectl delete namespace app # 删除命名空间创建Deployment（副本控制器）
bash
kubectl create deployment nginx-wl --image=nginx -n kube-public
kubectl create deployment
kubectl run 自主式的pod 静态
###描述某个资源的详细信息
kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public
kubectl get pods -n kube-public登录容器与删除****Pod
bash
kubectl exec -it nginx-wl-d47f99cb6-hv6gz bash -n kube-public
kubectl delete pod nginx-wl-d47f99cb6-hv6gz -n kube-public
#若pod无法删除，总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退
出，0表示立即终止pod扩缩容与删除
bash
kubectl scale deployment nginx-wl --replicas=2 -n kube-public
kubectl scale deployment nginx-wl --replicas=1 -n kube-public
kubectl delete deployment nginx-wl -n kube-public项目生命周期管理
项目的生命周期包括：
创建**→发布→更新→回滚→**删除
创建阶段（kubectl create）
创建并运行一个或多个容器镜像。
●创建一个deployment 或job 来管理容器。
kubectl create --help
bash
//启动 nginx 实例，暴露容器端口 80，设置副本数 3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl get pods
kubectl get all发布阶段（kubectl expose）
将资源暴露为 Service
bash
kubectl expose --help
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service
--type=NodePort|--------------|-------------------------|
| 类型 | 说明 |
| ClusterIP | 集群内部访问（默认） |
| NodePort | 集群外部访问，端口范围 30000-32767 |
| LoadBalancer | 云平台负载均衡 |
| externalName | 映射到外部域名 |
② 扩展端口类型
-
port port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service
- nodePort
nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个service - targetPort
targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。 - containerPort containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort。
查看网络状态与服务端口
bashNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/nginx-6f7f946b65-ptxdw 1/1 Running 1 24h 10.244.2.23 node02 <none> <none> pod/nginx-blue-9787b68d7-cfk55 1/1 Running 1 24h 10.244.2.21 node02 <none> <none> pod/nginx-blue-9787b68d7-xljtc 1/1 Running 1 24h 10.244.1.21 node01 <none> <none> pod/nginx-deployment-746ccc65d8-2zzd8 1/1 Running 1 23h 10.244.1.22 node01 <none> <none> pod/nginx-deployment-746ccc65d8-7zmzm 1/1 Running 1 23h 10.244.2.26 node02 <none> <none> pod/nginx-deployment-746ccc65d8-p9vzg 1/1 Running 1 23h 10.244.2.22 node02 <none> <none> pod/nginx-green-799d8cf57c-n52j4 1/1 Running 1 23h 10.244.2.24 node02 <none> <none> pod/nginx-green-799d8cf57c-tszz5 1/1 Running 1 23h 10.244.1.17 node01 <none> <none>负载均衡查看（节点上）
bash#在 node01 节点上操作，查看负载均衡端口 yum intsall -y ipvsadm [root@node01 ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.17.0.1:30425 rr -> 10.244.1.17:80 Masq 1 0 0 -> 10.244.2.24:80 Masq 1 0 0 TCP 172.17.0.1:31630 rr -> 10.244.1.22:80 Masq 1 0 0 -> 10.244.2.22:80 Masq 1 0 0 -> 10.244.2.23:80 Masq 1 0 0 -> 10.244.2.26:80 Masq 1 0 0 TCP 192.168.10.174:30000 rr -> 10.244.1.24:8443 Masq 1 0 0 TCP 192.168.10.174:30425 rr -> 10.244.1.17:80 Masq 1 0 0 -> 10.244.2.24:80 Masq 1 0 0 TCP 192.168.10.174:30426 rr -> 10.244.1.22:80 Masq 1 0 0 -> 10.244.2.22:80 Masq 1 0 0 -> 10.244.2.23:80 Masq 1 0 0 -> 10.244.2.26:80 Masq 1 0 0 TCP 192.168.10.174:31630 rr -> 10.244.1.22:80 Masq 1 0 0 -> 10.244.2.22:80 Masq 1 0 0 -> 10.244.2.23:80 Masq 1 0 0 -> 10.244.2.26:80 Masq 1 0 0 TCP 10.96.0.1:443 rr -> 192.168.10.173:6443 Masq 1 5 0 TCP 10.96.0.10:53 rr -> 10.244.0.5:53 Masq 1 0 0 -> 10.244.0.6:53 Masq 1 0 0 TCP 10.96.0.10:9153 rr -> 10.244.0.5:9153 Masq 1 0 0 -> 10.244.0.6:9153 Masq 1 0 0 TCP 10.96.33.86:80 rr persistent 10800 -> 10.244.1.19:8080 Masq 1 0 0 TCP 10.96.57.180:443 rr -> 10.244.1.24:8443 Masq 1 0 0 TCP 10.96.70.196:80 rr persistent 10800 -> 10.244.1.16:8080 Masq 1 0 0 TCP 10.96.89.7:8000 rr -> 10.244.2.25:8000 Masq 1 0 0 TCP 10.96.108.190:80 rr -> 10.244.1.17:80 Masq 1 0 0 -> 10.244.2.24:80 Masq 1 0 0 TCP 10.96.159.116:80 rr -> 10.244.1.22:80 Masq 1 0 0 -> 10.244.2.22:80 Masq 1 0 0 -> 10.244.2.23:80 Masq 1 0 0 -> 10.244.2.26:80 Masq 1 0 0 TCP 10.96.222.235:80 rr###在master01操作 查看访问日志
更新阶段（kubectl set）
修改容器镜像bash更改现有应用资源一些信息。 kubectl set --help //获取修改模板 kubectl set image --help Examples: # Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'. kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 //查看当前 nginx 的版本号 curl -I http://192.168.10.173:31630 curl -I http://192.168.10.174:31630##将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
kubectl get pods -w #/处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新
的pod，然后删除一个旧的pod，往后依次类推
kubectl get pods -o wide #再看更新好后的 Pod 的 ip 会改变回滚阶段（kubectl rollout）
bash##对资源进行回滚管理 kubectl rollout --help //查看历史版本 kubectl rollout history deployment/nginx //执行回滚到上一个版本 kubectl rollout undo deployment/nginx //执行回滚到指定版本 kubectl rollout undo deployment/nginx --to-revision=1 //检查回滚状态 kubectl rollout status deployment/nginx删除阶段（kubectl delete）
bash/删除副本控制器 kubectl delete deployment/nginx //删除service kubectl delete svc/nginx-service kubectl get all发布策略
Deployment控制器支持自定义控制更新过程中的滚动节奏，如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用， 主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
- nodePort