Как исправить ошибку dial tcp 10.96.0.1:443: тайм-аут ввода-вывода для модуля оператора, установленного через helm-rook?

Я в значительной степени добавил репо с помощью этой команды

helm repo add rook-stable https://charts.rook.io/stable

Затем я выполнил команду

helm install --namespace rook-ceph-system <NAME> <CHART VERSION>

Оператор сначала создается, но затем превращается в ошибку crashloopbackoff.

Ниже журнал.

kubectl logs  rook-ceph-operator-5bdc9cfcb9-qml5n
2020-02-26 17:42:38.863455 I | rookcmd: starting Rook v0.9.3 with arguments '/usr/local/bin/rook ceph operator'
2020-02-26 17:42:38.863570 I | rookcmd: flag values: --alsologtostderr=false, --help=false, --log-level=INFO, --log_backtrace_at=:0, --log_dir=, --logtostderr=true, --mon-healthcheck-interval=45s, --mon-out-timeout=5m0s, --stderrthreshold=2, --v=0, --vmodule=
2020-02-26 17:42:39.056154 I | cephcmd: starting operator
failed to get pod. Get https://10.96.0.1:443/api/v1/namespaces/default/pods/rook-ceph-operator-5bdc9cfcb9-qml5n: dial tcp 10.96.0.1:443: i/o timeout

Есть идеи, как это исправить?


ceph kubernetes-rook kubernetes-helm rook-storage cephfs
person CoderDude74    schedule 26.02.2020    source источник
comment
10.96.0.1:443 - это адрес по умолчанию для сервера API, что означает, что ваша установка не может взаимодействовать с плоскостью управления. Есть несколько вещей, которые могут вызвать это - не могли бы вы рассказать больше о своей настройке? Например: вы подтвердили, что ваш поставщик CNI (например, фланель, ткань, бязь и т. Д.) Установлен и работает? Ваши kube-proxy стручки здоровы? Что произойдет, если вы kubectl exec войдете в другой модуль и попытаетесь получить доступ к серверу API?   -  person Jesse Stuart    schedule 27.02.2020
comment
@JesseStuart спасибо за ответ, очень признателен. Я использую calico, и когда я запускаю kubectl get pods --all-namespaces, вся система kube работает. В моей конфигурации .kube мой адрес сервера API 192.168.50.10:6443. Могу ли я изменить сервер API с 10.96.0.1:443 на 192.168.50.10:6443? Также стоит упомянуть, что я не использую облачного провайдера, я использую k8s на голом железе. Кластерный IP работать не будет.   -  person CoderDude74    schedule 28.02.2020
comment
какие-либо обновления относительно вашей проблемы? потому что я точно в такой же ситуации. Я не знаю, почему он пытается вызвать сервер API на 10.96.0.1:443   -  person Peter Dev    schedule 13.03.2020

Ответы (1)


arrow_upward
2
arrow_downward

Была такая же проблема с почти такой же настройкой. Кластер Kubernetes развернут с 3 ВМ (через бродягу). Бязь как сеть стручков.

Что я исправил: объявить 3 имени хоста виртуальных машин в каждом / etc / hosts

192.168.100.51  kube1   kube1
192.168.100.52  kube2   kube2
192.168.100.53  kube3   kube3

Измените pod-network-cidr:

kubeadm init --apiserver-advertise-address=192.168.100.51 --apiserver-cert-extra-sans=192.168.100.51 --node-name kube1 --pod-network-cidr=10.10.0.0/16

Используйте тот же под-сидр в бязи:

- name: CALICO_IPV4POOL_CIDR
  value: "10.10.0.0/16"

Размещение ладьи:

git clone --single-branch --branch release-1.2 https://github.com/rook/rook.git
cd cluster/examples/kubernetes/ceph
kubectl create -f common.yaml
kubectl create -f operator.yaml
kubectl create -f cluster-test.yaml

Теперь кластер Ceph запущен и работает.

person Peter Dev    schedule 17.03.2020
comment
У меня была проблема. Ссылаюсь и исправляю конфигурацию кластера кубернетов. Тогда все работает нормально. Я предполагаю, что pod-network-cidr является основной причиной этой проблемы. Но я не знаю, почему именно? Руководство для calico cni pod-network-cidr - 192.168.0.0/16. Похоже на конфликт с диапазоном ip узла. Но я не уверен, что столкнулся с аналогичной проблемой с cni фланелевой сети (10.240.0.0/16). - person user3373742; 22.03.2021