Чтобы указать флаг --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: {}