1. 基础命令

# 1. 查看deployment
kubectl get deployment -n 命名空间
kubectl get deployment -n flink

# 2. 查看deployment描述
kubectl describe deployment deployment名称  -n 命名空间
kubectl describe deployment flink-jobmanager  -n flink

# 3. 查看pod
kubectl get pod -n 命名空间
kubectl get pod -n flink

# 4. 查看pod描述信息
kubectl describe pod pod名称 -n 命名空间
kubectl describe pod flink-jobmanager-56d5ff7676 -n flink

# 5. 查看pod日志
kubectl logs pod名称 -n 命名空间
kubectl logs kube-controller-manager-k8s-single -n kube-system

# 6. 查看运行的docker镜像
docker ps -a|grep 相关的镜像名称
docker ps -a|grep flink

# 7. 查看docker镜像日志
docker logs CONTAINER_ID
docker logs c1363285eea3

# 8. 查看k8s集群节点标签
# 查看标签
kubectl get node --show-labels
# 打标签
kubectl label node 节点名称 key=value

# 9. 查看作业是否可以被调度到集群节点
# SchedulingDisabled 表示不可被调度到
kubectl get nodes -A
# 指定某个节点不能被作业调度到
kubectl uncordon 节点名称 # 例子 kubectl uncordon bigdata-op-0001
# 指定某个节点可以被作业调度到
kubectl cordon 节点名称 # 例子 kubectl uncordon bigdata-op-0002

# 10.查看pod在哪个节点上
kubectl get pod pod名称 -n flink-dev -o wide

# 11.查看pod对应的yaml信息
kubectl get pod pod名称 -n flink-dev -o yaml

# 12. 滚动重启pod
# 查看指定命名空间下面得deployments
kubetl get deployments -n 命名空间
# 滚动重启指定deployment下面得pods
kubectl rollout restart deployment/具体deployment名称 -n 命名空间
# 查看滚动重启进度
kubectl rollout status deployment/具体deployment名称 -n 命名空间
# 查看pods启动动态
kubectl get pods -n 命名空间 -w  

# 13. 删除pods
# 单个pods删除
kubectl delete pod pod名 -n 命名空间 
# 删除多个pods
kubectl delete pod pod1 pod2 pod3 -n 命名空间 
# 强制pod
kubectl delete pod pod名 -n 命名空间 --force

2.常见故障

3.声明式对象模型（Object Model）

在 K8s 中，不需要写复杂的脚本去“启动容器”，你只需要写一份 YAML 配置文件（声明书），告诉 K8s 最终想要的状态。

3.1 YAML 的“基因组”：四大核心字段

所有的 K8s 资源文件，无论多么复杂，都必须包含这四个“顶级字段”：

1. apiVersion: 资源的 API 版本（如 v1, apps/v1）。

2. kind: 资源的类型（如 Pod, Deployment, Service）。

3. metadata: 资源的元数据，包括 name（名字）、namespace（命名空间）和最重要的 labels（标签）。

4. spec: 规格说明（这是最核心的部分），定义了你希望该资源达到的期望状态（比如镜像名、端口、副本数）。

3.2 核心资源对象及其协作关系

为了让应用跑起来，通常需要这三剑客：Deployment、Service 和 Ingress。

1. Deployment：副本控制器（负责“活着”）

Deployment 并不直接操作容器，它管理 Pod。它的主要职责是：

• 副本管理： 确保指定数量的 Pod 在运行。

• 自愈： Pod 挂了，它负责重启。

• 版本控制： 负责滚动更新和回滚。

2. Service：逻辑负载均衡（负责“找得到”）

Pod 的 IP 是动态的，经常变化。Service 提供了一个固定的虚拟 IP 和 DNS 名称。它通过 Label Selector（标签选择器） 找到背后的 Pod 集合，并将流量分发给它们。

3. Ingress：集群入口网关（负责“外部接入”）

Service 只能在集群内部访问。如果你想让互联网用户通过 www.myapp.com 访问你的应用，就需要 Ingress。它就像一个 nginx 反向代理，负责处理域名转发和 SSL 证书。

3.3 实操：一个完整的部署 YAML 案例

假设我们要部署一个简单的 Web 应用，以下是它的“出生证明”：

# 1. 定义 Deployment (部署应用)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
  labels:
    app: my-web        # 定义标签
spec:
  replicas: 3          # 运行 3 个副本
  selector:
    matchLabels:
      app: my-web      # 寻找带有此标签的 Pod
  template:            # Pod 的模板
    metadata:
      labels:
        app: my-web
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

---
# 2. 定义 Service (暴露端口)
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: my-web        # 关键点：通过标签关联上面的 Pod
  ports:
    - protocol: TCP
      port: 80         # Service 端口
      targetPort: 80   # 容器端口
  type: ClusterIP      # 集群内部访问

3.4 逻辑连连看：Label 与 Selector 的“红娘”机制

K8s 架构设计中最精妙的地方：解耦。

• Deployment 说：“我只管身上贴着 app: my-web 标签的 Pod，少一个我就补一个。”

• Service 说：“我也只管身上贴着 app: my-web 标签的 Pod，有流量我就分发给它们。”

• Pod 只需要老老实实贴上标签，至于谁在管它，它完全不关心。

这种基于**标签（Labels）**的松耦合架构，使得 K8s 能够极其灵活地处理成千上万个容器的关联关系。

3.5 总结

K8s 的架构逻辑可以概括为：

1. 用户 通过 YAML 描述期望状态。

2. API Server 接收并记录到 etcd。

3. Controller Manager 发现现实与期望不符。

4. Scheduler 决定 Pod 跑在哪。

5. Kubelet 在节点上把容器拉起来。

6. Service/Ingress 把流量引进去。