Calicoctl отклоняет сертификат при новой установке k3s

У меня есть свежая установка Ubuntu, свежая установка k3s и свежая загрузка Calicoctl. Я установил его следующим образом.

      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"

Когда я запускаю kubectl, все работает нормально. Когда я запускаю Calicoctl, я получаю ошибки сертификата.

      # calicoctl apply -f V000_000-host-policy.yaml 
Unable to get Cluster Information to verify version mismatch: Get "https://127.0.0.1:6443/apis/crd.projectcalico.org/v1/clusterinformations/default": x509: certificate signed by unknown authority
Use --allow-version-mismatch to override.

я скопировалrequest-header-ca.crt,client-ca.crtиserver-ca.crtсертификаты от/var/lib/rancher/k3s/server/tlsк/usr/local/share/ca-certificatesи применил их сupdate-ca-certificates. Я могу подтвердить, что сертификаты перечислены в/etc/ssl/certs/ca-certificates.crt.

Кроме того, мой~/.kube/configфайл имеет следующее содержимое (я регулярно переустанавливаю, ничего из этого не является конфиденциальным, я надеюсь - поправьте меня, если я ошибаюсь)

      apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0t...LS0K
    server: https://127.0.0.1:6443
  name: default
contexts:
- context:
    cluster: default
    user: default
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
  user:
    client-certificate-data: LS0t...LS0K
    client-key-data: LS0t...LQo=

И у меня есть следующая конфигурация в/etc/cni/net.d/calico-kubeconfig

      # Kubeconfig file for Calico CNI plugin. Installed by calico/node.
apiVersion: v1
kind: Config
clusters:
- name: local
  cluster:
    server: https://10.43.0.1:443
    certificate-authority-data: "LS0t...tLS0K"
users:
- name: calico
  user:
    token: eyJhb...tk4Q
contexts:
- name: calico-context
  context:
    cluster: local
    user: calico
current-context: calico-context

Я изменил адрес в Calico-kubeconfig с10.43.0.1:443к127.0.0.1:6443но это не имело никакого значения.

Кто-нибудь знает, как обойти это? Является ли ошибка сертификата, которую я вижу, следствием CA или токенов? Curl по тому же адресу также жалуется на CA, поэтому я думаю, что это не связано с токеном.

2 ответа

Установив уровень журнала Calicoctl для отладки (например.calicoctl -l debug get nodes) Я обнаружил, что происходит.

По умолчанию Calicoctl читает . Этот файл не будет существовать, если вы установили Calicoctl так, как я. Таким образом, клиент возвращается к использованию~/.kube/config. Который содержит некоторую информацию, но не всю информацию.

В составе информации журнала отладки также отображается загруженная конфигурация. Мне удалось сделать вывод, что свойства конфигурации немного отличаются от тех, что указаны в документации .

Я создал следующее/etc/calico/calicoctl.cfgфайл (формат yaml)

      apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "kubernetes"
  kubeconfig: "/home/user/.kube/config"
  K8sAPIToken: "eyJh...xQHA"
  K8sCAFile: "/var/lib/rancher/k3s/server/tls/server-ca.crt"

ГдеK8sAPITokenя взял из/etc/cni/net.d/calico-kubeconfig. Это должен быть тот же токен, что и в вопросе, я не уверен, почему он изменился (обновить?). В любом случае, описанный выше метод решает проблему (по крайней мере, временно).

У меня похожая установка (кромеk3sработающий внутри непривилегированного контейнера Ubuntu LXD) сk3s.serviceначал использовать:

      ExecStart=/usr/local/bin/k3s \
    server --snapshotter=native \
    --kubelet-arg=feature-gates=KubeletInUserNamespace=true \
    --kube-controller-manager-arg=feature-gates=KubeletInUserNamespace=true \
    --kube-apiserver-arg=feature-gates=KubeletInUserNamespace=true,RemoveSelfLink=false \
    --disable=servicelb --disable=traefik --flannel-backend=none --disable-network-policy \
    --cluster-cidr=192.168.0.0/16 --cluster-init

Никаких сертификатов копировать мне не потребовалось — достаточно было просто:

ln -s /etc/rancher/k3s/k3s.yaml ~/.kube/config

Другие вопросы по тегам