Сохранение команды соединения в серверной памяти, сгенерированной из kubeadm init - PullRequest
Новая
       52

Сохранение команды соединения в серверной памяти, сгенерированной из kubeadm init

0 голосов
/ 08 февраля 2020

Я хочу управлять серверами и настроить их на ansible. После создания команды соединения с помощью kubeadm я хочу сохранить команду в оперативной памяти контроллера. И сохранение команды секретного соединения локально на компьютере контроллера проблематично c для моей работы. В некоторых случаях Ansible Vault не подходит для меня, с чем я могу работать.
Есть ли способ сохранить команду соединения и передать ее рабочим узлам без локального сохранения на компьютере контроллера? С недолговечным токеном все в порядке, если я могу присоединить новые узлы к кластеру.

Любой безопасный способ, не требующий сохранения команды или токена соединения в локальном хранилище и новых узлов, которые могут присоединиться через длительный период времени, будет работать для меня.

1 Ответ

0 голосов
/ 02 апреля 2020

Я создаю небольшие кластеры с ansible, и у меня тоже была эта проблема.

Моим первым решением было именно то, что вы говорите, что не хотите делать ... команда соединения ( Как получить последние две строки из инициализации ansible (register stdout) кластера kubernetes ) Я выбрал другой вариант для простоты, а не для безопасности, так как это было болезненно, потому что мне пришлось изменить разрешения для команды соединения файл после того, как он был скопирован на сервер ansible, чтобы пользователь, которого я запускал playbooks, мог его прочитать ... А если бы я использовал его для второго кластера, команда join изменилась бы, и я бы потерял старый и не могу добавить узлы в предыдущий кластер ... в любом случае.

Мое второе решение, которое мне понравилось больше, таково:

Я создал файл инициализации yml для своих узлов, который включает в себя длинный термин token (не уверен, что у вас возникнут проблемы с долгоживущим токеном), созданный на master. Поэтому, когда я kubeadm init мои узлы, я сначала ansible копия в файле инициализации, а затем init с ним.

ansible фрагменты: 

  - name: Create the kubernetes init yaml file for worker node
    template:
      src: kubeadminitworker.yml
      dest: /etc/kubernetes/kubeadminitworker.yaml

  - name: Join the node to cluster
    command: kubeadm join --config /etc/kubernetes/kubeadminitworker.yaml
    register: join_output
  - debug:
      var: join_output.stdout

kubeadmininitworker.yml: 

apiVersion: kubeadm.k8s.io/v1beta2
caCertPath: /etc/kubernetes/pki/ca.crt
discovery:
  file:
    kubeConfigPath: /etc/kubernetes/discovery.yml
  timeout: 5m0s
  tlsBootstrapToken: <token string removed for post>
kind: JoinConfiguration
nodeRegistration:
  criSocket: /var/run/dockershim.sock
  kubeletExtraArgs:
    cloud-provider: external

Где строка токена совпадает с тем, что находится на мастере.

Я также использовал файл инициализации при создании мастера с ansible, который включал мой долгосрочный токен.

master init для справки: 

apiVersion: kubeadm.k8s.io/v1beta2
kind: InitConfiguration
bootstrapTokens:
       - groups:
         - system:bootstrappers:kubeadm:default-node-token
         token: <token string removed for post>
         ttl: 0s
         usages:
         - signing
         - authentication
nodeRegistration:
  kubeletExtraArgs:
    cloud-provider: external
---
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
useHyperKubeImage: false
networking:
  serviceSubnet: "10.96.0.0/12"
  podSubnet: "172.16.0.0/16"
etcd:
  local:
    imageRepository: "k8s.gcr.io"
dns:
  type: "CoreDNS"
  imageRepository: "k8s.gcr.io"

Я делал это некоторое время go - но я считаю, что я просто выполнил команду create token на существующем кластере, скопировал строку токена в два файла init и затем удалил токен из существующего кластера. Пока все хорошо ...

...