кластер не имеет стабильного адреса controlPlaneEndpoint - PullRequest
0 голосов
/ 20 февраля 2020

Когда я присоединяю новый узел в качестве мастера к моему кластеру. Я получаю ошибку. моя кластерная версия 1.17.0. Команда I exe c на узле: kubeadm join 192.168.1.120:6443 --token 5hbl78.99jlbgerstlkecss --discovery-token-ca-cert-hash sha256:0beb43185fa6a346fe57bd97cbb22afb128e6267bb80403ba2e7f388588e3256 --control-plane --certificate-key a056ad6f0ba73e736401027a1f078d7195b1aadaf2ac2eca6d773edc98d01483

Я получаю следующие ошибки:

[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
error execution phase preflight: 
One or more conditions for hosting a new control plane instance is not satisfied.

unable to add a new control plane instance a cluster that doesn't have a stable controlPlaneEndpoint address

Please ensure that:
* The cluster has a stable controlPlaneEndpoint address.
* The certificates that must be shared among control plane instances are provided.


To see the stack trace of this error execute with --v=5 or higher 

Конфигурация kubeadm на главном узле:

root@k8s-master01:kubernetes#kubectl -n kube-system get cm kubeadm-config -oyaml
apiVersion: v1
data:
  ClusterConfiguration: |
    apiServer:
      certSANs:
      - 192.168.1.120
      - 192.168.1.121
      - 192.168.1.122
      extraArgs:
        authorization-mode: Node,RBAC
      timeoutForControlPlane: 4m0s
    apiVersion: kubeadm.k8s.io/v1beta2
    certificatesDir: /etc/kubernetes/pki
    clusterName: kubernetes
    controllerManager: {}
    dns:
      type: CoreDNS
    etcd:
      external:
        caFile: /work/deploy/kubernetes/security/ca.pem
        certFile: /work/deploy/kubernetes/security/etcd.pem
        endpoints:
        - https://192.168.1.120:2379
        - https://192.168.1.121:2379
        - https://192.168.1.122:2379
        keyFile: /work/deploy/kubernetes/security/etcd.key
    imageRepository: registry.aliyuncs.com/google_containers
    kind: ClusterConfiguration
    kubernetesVersion: v1.17.0
    networking:
      dnsDomain: cluster.local
      podSubnet: 192.168.0.0/16
      serviceSubnet: 10.10.0.0/16
    scheduler: {}
  ClusterStatus: |
    apiEndpoints:
      k8s-master01:
        advertiseAddress: 192.168.1.120
        bindPort: 6443
    apiVersion: kubeadm.k8s.io/v1beta2
    kind: ClusterStatus
kind: ConfigMap
metadata:
  creationTimestamp: "2020-02-20T05:27:10Z"
  name: kubeadm-config
  namespace: kube-system
  resourceVersion: "8315"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kubeadm-config
  uid: a32b2f9b-41c3-4822-b8cb-c30c922fbddb

Эта проблема упоминалась в StackOverflow, но не была решена

Я сбрасываю кластер и очищаю данные etcd. Затем я настроил VIP с keepalive, и я настроил балансировку нагрузки VIP для двух узлов (которые я планирую использовать как два главных узла) с помощью haproxy. После этого я настроил kubeadm-config.yaml. измените значение controlPlaneEndpoint, чтобы оно было VIP: ПОРТ LB. затем я исполняю c "kubeadm init --config kubeadm.conf --upload-certs". Я получаю следующие ошибки:

[control-plane] Creating static Pod manifest for "kube-scheduler"
W0221 10:58:26.827277   18370 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
    timed out waiting for the condition

This error is likely caused by:
    - The kubelet is not running
    - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
    - 'systemctl status kubelet'
    - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
    - 'docker ps -a | grep kube | grep -v pause'
    Once you have found the failing container, you can inspect its logs with:
    - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
**root@k8s-master01:kubernetes#journalctl -xeu kubelet**
2月 21 11:05:04 k8s-master01 kubelet[22546]: E0221 11:05:04.698260   22546 reflector.go:156] k8s.io/kubernetes/pkg/kubelet/kubelet.go:449: Failed to list *v1.Service: Get https://192.168.1.121:6443/api/v1/services?limit=500&resour
2月 21 11:05:04 k8s-master01 kubelet[22546]: E0221 11:05:04.781676   22546 kubelet.go:2263] node "k8s-master01" not found
2月 21 11:05:04 k8s-master01 kubelet[22546]: E0221 11:05:04.881928   22546 kubelet.go:2263] node "k8s-master01" not found
2月 21 11:05:04 k8s-master01 kubelet[22546]: E0221 11:05:04.895805   22546 reflector.go:156] k8s.io/kubernetes/pkg/kubelet/kubelet.go:458: Failed to list *v1.Node: Get https://192.168.1.121:6443/api/v1/nodes?fieldSelector=metadata
2月 21 11:05:04 k8s-master01 kubelet[22546]: E0221 11:05:04.983615   22546 kubelet.go:2263] node "k8s-master01" not found
2月 21 11:05:05 k8s-master01 kubelet[22546]: E0221 11:05:05.084247   22546 kubelet.go:2263] node "k8s-master01" not found
2月 21 11:05:05 k8s-master01 kubelet[22546]: E0221 11:05:05.106561   22546 reflector.go:156] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://192.168.1.121:6443/api/v1/pods?fieldSelector=sp
2月 21 11:05:05 k8s-master01 kubelet[22546]: E0221 11:05:05.184665   22546 kubelet.go:2263] node "k8s-master01" not found
2月 21 11:05:05 k8s-master01 kubelet[22546]: E0221 11:05:05.284792   22546 kubelet.go:2263] node "k8s-master01" not found

Другая информация: Конечная точка моего VIP: 192.168.1.200:6001. И haproxy LB VIP 'оконечная точка к двум оконечным точкам главного сервера (192.168.1.120:6443, 192.168.1.121:6443)

1 Ответ

1 голос
/ 20 февраля 2020

При настройке первого главного узла с использованием kubeadm вы должны выполнить следующую команду:

sudo kubeadm init --config kubeadm-config.yaml --upload-certs

Проверьте содержимое файла kubeadm-config.yaml. Он должен иметь controlPlaneEndpoint. Значение должно быть LOAD_BALANCER_DNS:LOAD_BALANCER_PORT.

Теперь, если у вас нет Loadabalancer перед вашим сервером Kubernetes API, который рекомендуется, вы можете установить его на publi c IP главного узла.

Флаг --upload-certs должен учитывать ошибку, связанную с сертификатом.

Также вы можете отредактировать ConfigMap и добавить controlPlaneEndpoint.

Содержимое kubeadm-config. yaml должен выглядеть как

    apiVersion: kubeadm.k8s.io/v1beta2
    kind: ClusterConfiguration
    kubernetesVersion: stable
    controlPlaneEndpoint: "192.168.1.200:6001"
    apiServer:
      certSANs:
      - 192.168.1.120
      - 192.168.1.121
      - 192.168.1.122
      - 192.168.1.200
      extraArgs:
        authorization-mode: Node,RBAC
    etcd:
      external:
        endpoints:
        - https://192.168.1.120:2379
        - https://192.168.1.121:2379
        - https://192.168.1.122:2379
        caFile: /work/deploy/kubernetes/security/ca.pem
        certFile: /work/deploy/kubernetes/security/etcd.pem
        keyFile: /work/deploy/kubernetes/security/etcd.key
    networking:
      dnsDomain: cluster.local
      podSubnet: 192.168.0.0/16
      serviceSubnet: 10.10.0.0/16
...