Calicoctl respinge certificatul pentru instalarea proaspătă a K3s

Am o nouă instalare a Ubuntu, o nouă instalare a k3s și o nouă descărcare a calicoctl. L-am instalat în felul următor.

curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644"\
        INSTALL_K3S_EXEC="--flannel-backend=none --cluster-cidr=192.168.0.0/16\
        --disable-network-policy --disable=traefik" sh -

kubectl create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml
kubectl create -f https://docs.projectcalico.org/manifests/custom-resources.yaml

curl -o calicoctl -O -L "https://github.com/projectcalico/calicoctl/releases/download/v3.20.2/calicoctl"

Când rulez kubectl, totul funcționează bine. Când rulez calicoctl, primesc erori de certificat.

# calicoctl apply -f V000_000-host-policy.yaml 
Nu se pot obține informații despre cluster pentru a verifica nepotrivirea versiunii: obțineți „https://127.0.0.1:6443/apis/crd.projectcalico.org/v1/clusterinformations/default”: x509: certificat semnat de o autoritate necunoscută
Utilizați --allow-version-mismatch pentru a înlocui.

am copiat cerere-header-ca.crt, client-ca.crt și server-ca.crt certificate de la /var/lib/rancher/k3s/server/tls la /usr/local/share/ca-certificates si le-a aplicat cu update-ca-certificate. Pot confirma că certificatele sunt listate în /etc/ssl/certs/ca-certificates.crt.

În plus, al meu ~/.kube/config fișierul are următorul conținut (fac reinstalări regulate, nimic din toate acestea nu este confidențial, sper - corectați-mă dacă greșesc)

apiVersion: v1
clustere:
- cluster:
    date-autoritatea-de-certificat: LS0t...LS0K
    server: https://127.0.0.1:6443
  nume: implicit
contexte:
- context:
    cluster: implicit
    utilizator: implicit
  nume: implicit
contextul curent: implicit
fel: Config
preferințe: {}
utilizatori:
- nume: implicit
  utilizator:
    date-certificat-client: LS0t...LS0K
    date-cheie-client: LS0t...LQo=

Și am următoarea configurație în /etc/cni/net.d/calico-kubeconfig

# Fișier Kubeconfig pentru pluginul Calico CNI. Instalat de calico/node.
apiVersion: v1
fel: Config
clustere:
- nume: local
  cluster:
    server: https://10.43.0.1:443
    certificate-authority-data: „LS0t...tLS0K”
utilizatori:
- nume: calico
  utilizator:
    simbol: eyJhb...tk4Q
contexte:
- nume: calico-context
  context:
    cluster: local
    utilizator: calico
context-actual: calico-context

Am schimbat adresa în calico-kubeconfig din 10.43.0.1:443 la 127.0.0.1:6443 dar asta nu avea nicio diferență.

Știe cineva cum să rezolve asta? Este eroarea certificatului pe care o văd o consecință a CA sau a simbolurilor? Curl la aceeași adresă se plânge și de CA, așa că mă face să cred că acest lucru nu are legătură cu simbolul.

Prin setarea nivelului de jurnal calicoctl la depanare (ex. calicoctl -l debug obține noduri) Am descoperit ce se întâmplă.

În mod implicit, calicoctl citește /etc/calico/calicoctl.cfg. Acest fișier nu va exista dacă ați instalat calicoctl așa cum am făcut eu.Deci clientul revine la utilizare ~/.kube/config. Care conține unele informații, dar nu toate informațiile.

Ca parte a informațiilor din jurnalul de depanare, este afișată și configurația încărcată. Am putut deduce că proprietățile de configurare erau ușor diferite de cele din documentatia.

Am creat următoarele /etc/calico/calicoctl.cfg fișier (format yaml)

apiVersion: projectcalico.org/v3
fel: CalicoAPIConfig
metadate:
specificație:
  datastoreType: „kubernetes”
  kubeconfig: „/home/user/.kube/config”
  K8sAPIToken: „eyJh...xQHA”
  K8sCAFile: „/var/lib/rancher/k3s/server/tls/server-ca.crt”

Unde K8sAPIToken am luat din /etc/cni/net.d/calico-kubeconfig. Ar trebui să fie același simbol cu ​​cel de la întrebare, nu sunt sigur de ce s-a schimbat (refresh?). În orice caz, metoda de mai sus rezolvă problema (cel puțin temporar).