Kubernetes + бязь + набор реплик

Так что я оказался в довольно сложной ситуации. Я пытаюсь создать простой набор реплик, но, к сожалению, у меня возникли проблемы с ситцем.

У меня 2 виртуальные машины, работающие на OracleVM. Я настроил их на использование интерфейса enp0s8. IP-адрес главного узла - 192.168.56.2, а IP-адрес рабочего узла - 192.168.56.3.

Вот что я делаю в Kubernetes. Сначала я создаю главный узел kubernetes:

kubeadm init --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=192.168.56.2

после успешной инициализации я бегу:

export KUBECONFIG=/etc/kubernetes/admin.conf

Теперь я создаю сеть POD, запустив:

kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml

после этого я успешно присоединяюсь к рабочему узлу. Всякий раз, когда я запускаю реплику с:

*** изменить: мне не нужно создавать набор реплик, чтобы получить тот же результат, что создание ситцевого узла застревает

kubectl create -f replicaset-definition.yml

в котором yml выглядит так:

kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
        - name: nginx-container
          image: nginx
  replicas: 2
  selector:
    matchLabels:
      app: myapp

Я создаю новый ситцевый узел, который в конечном итоге застрянет

calico-node-mcb5g                          0/1     Running   6          8m58s
calico-node-t9p5n                          1/1     Running   0          12m

Если я запускаю на нем kubectl logs -n kube-system calico-node-mcb5g -f, я получаю следующие журналы:

2020-03-18 14:45:40.585 [INFO][8] startup.go 275: Using NODENAME environment for node name
2020-03-18 14:45:40.585 [INFO][8] startup.go 287: Determined node name: kubenode1
2020-03-18 14:45:40.587 [INFO][8] k8s.go 228: Using Calico IPAM
2020-03-18 14:45:40.588 [INFO][8] startup.go 319: Checking datastore connection
2020-03-18 14:46:10.589 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: i/o timeout
2020-03-18 14:46:41.591 [INFO][8] startup.go 334: Hit error connecting to datastore - retry error=Get https://10.96.0.1:443/api/v1/nodes/foo: dial tcp 10.96.0.1:443: i/o timeout

Я попытался настроить calico.yml и добавил в env следующую строку:

- name: IP_AUTODETECTION_METHOD
  value: "interface=enp0s8"

но результат все тот же.

Большое вам спасибо за то, что прочитали это, и если у вас есть какие-либо советы, я буду ооочень признателен !!!


kubernetes calico project-calico replicaset
person minihulk22    schedule 18.03.2020    source источник
comment
проверьте, запущены ли прокси-модули kube и нет ли ошибок в журналах модулей kube-proxy   -  person Arghya Sadhu    schedule 18.03.2020
comment
хорошо, я проверяю прокси: `` ps auxw | grep kube-proxy корень 7912 0,0 1,4 140108 28724? Ssl 11:05 0:02 / usr / local / bin / kube-proxy --config = / var / lib / kube-proxy / config.conf --hostname-override = kubemaster root 19601 0,0 0,0 21292940 точек / 8 S + 12:09 0:00 grep --color = auto kube-proxy ''   -  person minihulk22    schedule 18.03.2020
comment
есть ли на узле брандмауэр, который блокирует трафик на 10.96.0.1:443   -  person Arghya Sadhu    schedule 18.03.2020

Ответы (1)


arrow_upward
0
arrow_downward

Хорошо, так что поехали. Казалось, что этот ситцевый узел разбился из-за перекрытия CIDR службы и CIDR хоста.

Если я инициирую главный узел с изменением CIDR как:

kubeadm init --pod-network-cidr=20.96.0.0/12 --apiserver-advertise-address=192.168.56.2

работает как шарм.

Это очень помогло: Создание кластера успешно, но calico-node-xx pod находится в состоянии CrashLoopBackOff

person minihulk22    schedule 19.03.2020