Kubernetes 资源

    确保您配置了正确的 kubeconfig(例如,Rancher 高可用时,)或者通过 Rancher UI 使用内嵌的 kubectl。

    运行以下命令并检查以下内容:

    • 集群中的所有节点都应列出,确保没有任何节点丢失。
    • 所有节点都应处于Ready状态(如果未处于Ready状态,请使用docker logs kubelet检查该节点上的kubelet容器日志)
    • 检查所有节点是否是正确的版本。
    • 检查 OS/内核/Docker 值是否按预期显示(如果不正确可能是由于升级了 OS/内核/Docker 而引起的问题)

    Copy

    输出示例:

    1. controlplane-0 Ready controlplane 31m v1.13.5 138.68.188.91 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5
    2. etcd-0 Ready etcd 31m v1.13.5 138.68.180.33 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5
    3. worker-0 Ready worker 30m v1.13.5 139.59.179.88 <none> Ubuntu 18.04.2 LTS 4.15.0-47-generic docker://18.9.5

    Copy

    获取节点 Conditions

    运行以下命令以列出节点 Conditions,关于节点 Conditions 请查看

    1. kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'

    Copy

    运行以下命令以列出节点有问题的 Conditions,关于节点 Conditions 请查看节点 Conditions

    1. kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{else}}{{if ne .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{": "}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'

    Copy

    输出示例:

    1. worker-0: DiskPressure:True

    Copy

    Kubernetes Controller Manager Leader

    leader 选举由选举程序决定。在确定了 leader 节点之后,leader 状态(holderIdentity) 将会保存在 kube-controller-manager endpoint 中 (在本示例中,leader 节点是controlplane-0)。

    1. kubectl -n kube-system get endpoints kube-controller-manager -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'
    2. {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>

    Copy

    Kubernetes Scheduler Leader

    leader 选举由选举程序决定。在确定了 leader 节点之后,leader 状态(holderIdentity) 将会保存在 kube-scheduler endpoint 中 (在本示例中,leader 节点是 controlplane-0)。

    1. {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}>

    Copy

    默认的 Ingress Controller 是 NGINX,并作为 DaemonSet 部署在ingress-nginx 命名空间中。只能将该 Pod 调度到具有worker角色的节点上。

    检查 Pod 是否在所有节点上运行:

    1. kubectl -n ingress-nginx get pods -o wide

    Copy

    1. kubectl -n ingress-nginx get pods -o wide
    2. NAME READY STATUS RESTARTS AGE IP NODE
    3. default-http-backend-797c5bc547-kwwlq 1/1 Running 0 17m x.x.x.x worker-1
    4. nginx-ingress-controller-4qd64 1/1 Running 0 14m x.x.x.x worker-1
    5. nginx-ingress-controller-8wxhm 1/1 Running 0 13m x.x.x.x worker-0

    Copy

    如果 Pod 无法运行(状态不是 RunningReady状态未显示为1/1,或者您看到大量的Restart次数),请检查 Pod 的详细信息,日志和 namespaces 事件。

    查看 Pod 详细信息

    Copy

    查看 Pod 容器日志

    1. kubectl -n ingress-nginx logs -l app=ingress-nginx

    Copy

    1. kubectl -n ingress-nginx get events

    Copy

    Debug 日志

    执行下面命令开启 debug 日志:

      Copy

      检查配置

      查看每个 Pod 中生成的配置:

      1. kubectl -n ingress-nginx get pods -l app=ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n ingress-nginx exec $pod -- cat /etc/nginx/nginx.conf; done

      Copy

      Rancher 通过 cluster-agent 与集群进行通信(通过cattle-cluster-agent调用 Kubernetes API 与集群通讯),并且通过cattle-node-agent与节点进行通信。

      cattle-node-agent

      检查是否每个节点都正常运行了 cattle-node-agent, 正确运行的状态应该是 Running 并且重启的次数应该不多。

      Copy

      输出示例:

      1. NAME READY STATUS RESTARTS AGE IP NODE
      2. cattle-node-agent-4gc2p 1/1 Running 0 2h x.x.x.x worker-1
      3. cattle-node-agent-8cxkk 1/1 Running 0 2h x.x.x.x etcd-1
      4. cattle-node-agent-kzrlg 1/1 Running 0 2h x.x.x.x etcd-0
      5. cattle-node-agent-nclz9 1/1 Running 0 2h x.x.x.x controlplane-0
      6. cattle-node-agent-pwxp7 1/1 Running 0 2h x.x.x.x worker-0
      7. cattle-node-agent-t5484 1/1 Running 0 2h x.x.x.x controlplane-1
      8. cattle-node-agent-t8mtz 1/1 Running 0 2h x.x.x.x etcd-2

      Copy

      检查特定节点上 cattle-node-agent 或者所有节点上 cattle-node-agent pods 的日志是否有错误:

      1. kubectl -n cattle-system logs -l app=cattle-agent

      Copy

      cattle-cluster-agent

      检查集群中是否正确运行了 cattle-cluster-agent,正确运行的状态应该是 Running 并且重启的次数应该不多。

      1. kubectl -n cattle-system get pods -l app=cattle-cluster-agent -o wide

      Copy

      Copy

      检查 cattle-cluster-agent pod 的日志是否有错误:

      1. kubectl -n cattle-system logs -l app=cattle-cluster-agent

      Copy

      检查所有 Pods/Jobs 的状态

      执行以下命令进行检查集群中所有 Pod/Job 是否正常运行:

      1. kubectl get pods --all-namespaces

      Copy

      Pods 和 Jobs 正确运行的状态应该是:

      • Running,并且重启的次数应该不多。
      • 或者是Completed,已经完成运行。
      1. kubectl describe pod POD_NAME -n NAMESPACE

      Copy

      查看 Pod 日志

      1. kubectl logs POD_NAME -n NAMESPACE

      Copy

      如果 Job 状态是 Completed 则可以通过以下命令检查未完成原因:

      查看 Job 详细信息

      1. kubectl describe job JOB_NAME -n NAMESPACE

      Copy

      查看 Job Pod 的日志

      1. kubectl logs -l job-name=JOB_NAME -n NAMESPACE

      Copy

      被驱逐的 Pod

      Pod 会根据驱逐信号中的描述进行驱逐。

      查看被逐出的 Pod 列表(Pod 名称和命名空间):

        Copy

        要删除所有被驱逐的 Pod,

        1. kubectl get pods --all-namespaces -o go-template='{{range .items}}{{if eq .status.phase "Failed"}}{{if eq .status.reason "Evicted"}}{{.metadata.name}}{{" "}}{{.metadata.namespace}}{{"\n"}}{{end}}{{end}}{{end}}' | while read epod enamespace; do kubectl -n $enamespace delete pod $epod; done

        Copy

        检查被逐出的 Pod,已调度节点的列表以及被驱逐的原因:

        Copy

        Job 的状态一直没有变更为 Completed

        因为 Istio Sidecarh 会无休止地运行,即使 Job 的任务完成了,它的状态也不能被视为Completed。上述步骤是在短期内处理这个问题的方法,它禁止了 Istio 和添加了 annotation 的 Pod 之间的通信。如果您使用了这种方式解决这个问题,这个 Job 就没有权限访问 service mesh,不能够用于集成测试。