Не удается обновить конфигурацию Calico CNI в кластере Kubernetes

Я обнаружил, что еще несколько месяцев назад конфигурация hostPort для модулей не работала. с интеграцией на основе CNI. Это означало, что для любого кластера Kubernetes, использующего Calico, было невозможно напрямую открыть порт пода непосредственно на порте определенного узла, без использования службы или отметки hostNetwork=true (что немного экстремально).

Начиная с Kubernetes 1.7.0 это возможно, но необходимо изменить конфигурацию Calico, чтобы позволить новый подключаемый модуль CNI "portmap", что я и пытаюсь сделать, но безуспешно. Я начинаю с нового кластера IBM Bluemix Container Service.

Мой ситцевый узел DaemonSet имеет следующую переменную среды CNI_NETWORK_CONFIG:

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "type": "calico",
  "etcd_endpoints": "__ETCD_ENDPOINTS__",
  "etcd_key_file": "__ETCD_KEY_FILE__",
  "etcd_cert_file": "__ETCD_CERT_FILE__",
  "etcd_ca_cert_file": "__ETCD_CA_CERT_FILE__",
  "log_level": "info",
  "mtu": 1480,
  "ipam": {
    "type": "calico-ipam"
  },
  "policy": {
    "type": "k8s",
    "k8s_api_root": "https://__KUBERNETES_SERVICE_HOST__:__KUBERNETES_SERVICE_PORT__",
    "k8s_auth_token": "__SERVICEACCOUNT_TOKEN__"
  },
  "kubernetes": {
    "kubeconfig": "__KUBECONFIG_FILEPATH__"
  }
}

Я просто пытался заменить его следующей конфигурацией:

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "plugins": [{
    "type": "calico",
    "etcd_endpoints": "__ETCD_ENDPOINTS__",
    "etcd_key_file": "__ETCD_KEY_FILE__",
    "etcd_cert_file": "__ETCD_CERT_FILE__",
    "etcd_ca_cert_file": "__ETCD_CA_CERT_FILE__",
    "log_level": "info",
    "mtu": 1480,
    "ipam": {
      "type": "calico-ipam"
    },
    "policy": {
      "type": "k8s",
      "k8s_api_root": "https://__KUBERNETES_SERVICE_HOST__:__KUBERNETES_SERVICE_PORT__",
      "k8s_auth_token": "__SERVICEACCOUNT_TOKEN__"
    },
    "kubernetes": {
      "kubeconfig": "__KUBECONFIG_FILEPATH__"
    }
  },
    {
      "type": "portmap",
      "snat": true,
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

calico-node pod'ы успешно работали после принудительной перезагрузки, но мои собственные Pod'ы продолжают зависать в статусе "Pending" во время инициализации из-за события "Error syncing pod" от "kubelet NODE_IP".

Буду признателен за помощь в этом вопросе. Заранее спасибо.


kubernetes project-calico cni ibm-cloud
person Emanuele Casadio    schedule 02.11.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

То, что у вас есть, выглядит разумным с точки зрения содержимого, я думаю, проблема может заключаться в том, что вам нужно изменить имя файла конфигурации с .conf на .conflist. Есть PR с некоторыми изменениями WIP https://github.com/projectcalico/calico/pull/903 для включения hostport в манифестах calico, вы можете сравнить это с тем, что вы сделали.

Если вы устанавливаете имя файла с помощью daemonset, вам следует удалить предыдущий файл конфигурации на хостах, потому что выпущенный контейнер install-cni не очищает предыдущую конфигурацию, и я не уверен, какой файл конфигурации будет использовать kubelet.

person Erik Stidham    schedule 06.11.2017
comment
Я изменил имя файла с .conf на .conflist, и теперь, по крайней мере, calico-node работает правильно, как и другие модули. К сожалению, я все еще не могу получить доступ к порту узла. Возможно, это старый файл конфигурации, создающий конфликт, или, что более вероятно, правило брандмауэра где-то в стеке. Все еще исследуем эту часть, но спасибо. - person Emanuele Casadio; 07.11.2017
comment
Хорошо, я добавил простой новый узел в кластер, и я все еще не могу получить доступ к порту, так что, скорее всего, это плохая конфигурация брандмауэра или что-то в этом роде. Я до сих пор не могу понять, где именно проблема. - person Emanuele Casadio; 07.11.2017
comment
Поскольку вы не уверены, что происходит с вашим трафиком, вы можете использовать tcpdump и sudo iptables-save -c | grep DROP (чтобы увидеть, приходит ли трафик на хост и не отбрасывается ли он хостом). - person Erik Stidham; 20.11.2017
comment
Оказывается, у IBM есть проблема с их облаком, поэтому эта конфигурация просто не может работать, пока они ее не исправят. :( - person Emanuele Casadio; 19.12.2017