我的用_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}'
複製代碼