kubeadm init - эквивалент флага -apiserver-advertise-address в файле конфигурации - PullRequest
1 голос
/ 25 февраля 2020

Мне нужно инициализировать мой кластер kubernetes с помощью файла конфигурации kubeadm из-за некоторых дополнительных аргументов, которые мне нужно передать, которые недоступны непосредственно для kubeadm init.

Я создал файл конфигурации, и он работает отлично. Я просмотрел документацию файла конфигурации kubeadm, но все еще не смог определить, какая опция эквивалентна флагу командной строки --apiserver-advertise-address

Моя версия kubeadm 1.15.7

Это мой текущий конфиг: закомментированные строки - это опции, которые я уже пробовал, но, похоже, они не работают.

#apiVersion: kubeadm.k8s.io/v1beta2
#kind: InitConfiguration
#APIEndpoint:
#  advertiseAddress: "192.168.224.22"
#  bindPort: 6443
#controlPlaneEndpoint: "192.168.224.22:6443"
apiServer:
  advertiseAddress: "192.168.224.22"
  extraArgs:
    authorization-mode: Node,RBAC
#    advertise-address: 192.168.224.22
    authentication-token-webhook-config-file: /webhook/webhook-config.yaml
  extraVolumes:
  - name: "webhook-conf"
    hostPath: "/webhook/"
    mountPath: "/webhook/"
    readOnly: true
    pathType: DirectoryOrCreate
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
#APIEndpoint:
#  advertiseAddress: "192.168.224.22"
#  bindPort: 6443
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: v1.15.10
networking:
#  advertiseAddress: "192.168.224.22"
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
scheduler: {}

Это - это то, что я пытаюсь настроить.

1 Ответ

2 голосов
/ 25 февраля 2020

Чтобы указать флаг --apiserver-advertise-address в файле конфигурации kubeadm, используйте его в конфигурации init:

localAPIEndpoint:
  advertiseAddress: 192.168.224.22
  bindPort: 6443

Первоначально, когда я использовал это, адрес изменился, но затем рабочие узлы не смогли присоединиться кластер из-за неправильной конфигурации сокета CRI.

Оказывается, использование kubeadm config view не распечатывает всю конфигурацию, которая использовалась при создании кластера. The kind: InitConfiguration пропускается, из-за чего произошла неправильная конфигурация.

Используйте kubeadm config print init-defaults, чтобы получить блок инициализации файла конфигурации. Тогда это должно работать.

Окончательный рабочий файл конфигурации:

apiVersion: kubeadm.k8s.io/v1beta2
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 192.168.224.22
  bindPort: 6443
nodeRegistration:
  criSocket: /var/run/dockershim.sock
  name: hostname1
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
---
apiServer:
  extraArgs:
    authorization-mode: Node,RBAC
    authentication-token-webhook-config-file: /webhook/webhook-config.yaml
  extraVolumes:
  - name: "webhook-conf"
    hostPath: "/webhook/"
    mountPath: "/webhook/"
    readOnly: true
    pathType: DirectoryOrCreate
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: v1.15.10
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
scheduler: {}
...