我的用_kubernetes_troubleshooting_reference

kubeadm相关

主机有双网卡，默认网卡为外网网卡，集群内通讯使用内网网卡

尝试从 apiServer 参数--advertise-address和 kubelet 参数--node-ip入手。

一个出错的典型场景:

好比在物理机上经过 vagrant 建立虚拟机部署 k8s 集群，虚拟机默承认能会配置一张 NAT 网卡做为默认网卡且这个 ip 多是同样的，那可能多个虚拟机的的默认网卡的 ip 都是同样的。

kube-dns 相关

kube-dns 的 service ip 更改致使集群内服务发现功能不可用

kube-dns 是 k8s 的一个集群内 dns 插件，解决集群内服务发现的问题。在没有任何 dns 解决方案的状况下，pod 也能够经过 service name 访问到 service，但前提是 service 建立在 pod 以前。其缘由是， apiserver 在建立 pod 的时候会将如今的集群内的 service 信息注入到容器中的环境变量。

假如集群内的 pod network CIDR 是 10.96.0.0/16，那 kube-dns 默认的 service ip 将会是 10.96.0.10，这个 ip 将会成为容器的 nameserver。加入由于 pod 网络 CIDR 发生变化，有可能 kube-dns 的 service ip 改变了，但容器中的 nameserver ip 没有及时同步。 关于集群内 DNS 的问题能够参考官网提供的经典问题分析。

认证与受权相关

查看 kubectl (其它组件原理一致)的上下文(context)与用户对应的 ClusterRole/Role。

查看链接集群的上下文

# 查看当前的 context 和 user
# 以下面例子，当前使用的是名为 kubernetes 的 context，用户是 kubectl
$ kubectl config get-contexts
CURRENT   NAME              CLUSTER      AUTHINFO   NAMESPACE
          backend-context   kubernetes   backend    work
*         kubernetes        kubernetes   kubectl    kube-system
# kubectl 使用的 config 文件通常为 ~/.kube/config，也可使用 KUBECONFIG 环境变量指定一个文件。
# cluster 为 k8s 集群信息，包括 ip、端口，若是集群开启了 --insecure-port 选项，则能够经过此端口绕过认证和受权。
$ ls -lh ~/.kube/config
-rw------- 1 root root 6.4K Apr 17 14:21 /root/.kube/config
# certificate-authority-data 实际上是 ca 证书通过 base64 加密后的内容，ca 证书为服务端(master)建立时生成的。
# client-certificate 或者 client-certificate-data 则是客户端(此处为 kubectl)经过 x509 认证机制，根据 ca 证书和客户端本身的私钥(client-key)生成的。具体步骤能够自行 Google。
$ cat ~/.kube/config
apiVersion: v1
clusters:
- cluster:
    ...
    server: https://30.99.3.138:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: work
    user: backend
  name: backend-context
- context:
    cluster: kubernetes
    namespace: kube-system
    user: kubectl
  name: kubernetes
current-context: kubernetes
kind: Config
preferences: {}
users:
- name: backend
  user:
    client-certificate: /root/work/backend.crt
    client-key: /root/work/backend.key
- name: kubectl
  user:
    client-certificate-data: ...
    client-key-data: ...
复制代码

查看证书内容

# Issuer 是 ca 证书发行方(master)设置的字段内容。
# kubernetes 系统中的用户有 2 种: 通常用户和service account。匿名用户默认名为: system:anonymous，所属组为: system:unauthenticated。
# Subject 是客户端(kubectl)设置的内容。CN(common name) 域用做通常用户的用户名，O(organization)域用做组名。、
# 因此这个context中的的用户名为backend，组为dev。
$ cat /root/work/backend.crt | openssl x509 -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            fe:0e:cd:8d:b9:07:fd:74
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN=kubernetes
        Validity
            Not Before: Apr 17 05:33:19 2019 GMT
            Not After : Apr 16 05:33:19 2020 GMT
        Subject: CN=backend, O=dev
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
...
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
...
复制代码

查看RoleBiding和Role

# RoleBinding 中的 subjects 中，有一个 user 名为 backend。这个 backend 就与 kubectl 的 context 中的 backend 用户相关联。这个用户的权限就是在 backend-role 这个 Role 中配置的。同理，subjects 中若是配置的是 group，则会和 kubectl config 文件中的 O 域相关联。
$ kubectl get rolebinding -n work
NAME                  AGE
backend-rolebinding   35s
$ kubectl get rolebinding backend-rolebinding -o yaml -n work
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"RoleBinding","metadata":{"annotations":{},"name":"backend-rolebinding","namespace":"work"},"roleRef":{"apiGroup":"","kind":"Role","name":"backend-role"},"subjects":[{"apiGroup":"","kind":"User","name":"backend"}]}
  creationTimestamp: 2019-04-18T06:24:27Z
  name: backend-rolebinding
  namespace: work
  resourceVersion: "7179659"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/work/rolebindings/backend-rolebinding
  uid: 9e1c691e-61a2-11e9-af73-06a624003bc9
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: backend-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: backend
$ kubectl get role backend-role -n work -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"backend-role","namespace":"work"},"rules":[{"apiGroups":[""],"resources":["pods"],"verbs":["get","list","watch"]}]}
  creationTimestamp: 2019-04-18T06:18:06Z
  name: backend-role
  namespace: work
  resourceVersion: "7178286"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/work/roles/backend-role
  uid: baafff88-61a1-11e9-bc36-063270003bc8
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
复制代码

验证 kubectl 的权限

# 能够看到使用 context 为backend-context的时候，确实只有对 work namespace 下的 pod 资源的查看权限。
$ kubectl config use-context backend-context
Switched to context "backend-context".
$ kubectl config current-context
backend-context
$ clear
$ kubectl get no
No resources found.
Error from server (Forbidden): nodes is forbidden: User "backend" cannot list nodes at the cluster scope
$ kubectl get service -n work
No resources found.
Error from server (Forbidden): services is forbidden: User "backend" cannot list services in the namespace "work"
$ kubectl get po -n work
No resources found.
$
复制代码

使用 jsonpath 来遍历 clusterrolebinding 和 rolebinding，看是否有指定的 user、group 被关联

kubectl get rolebinding -n work -o jsonpath='{range .items[*]}RolebindingName: {.metadata.name}{"\t"}SubjectNames: {.subjects[*].name}{"\n"}{end}'
复制代码