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
Спасибо первому ответу за подсказку.
Это также указано в многоузловой установке k3s .