/ assign @liztio

Veja # 598. Claramente, um bug, não uma solicitação de recurso, com base na saída de registro do kubeadm.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

/ assign @rdodev

você poderia verificar se isso ainda existe para 1.12 e atribuir o marco de 1.13 se puder reproduzir após todo o nosso embaralhamento

/ tipo bug

598 tem etapas de reprodução fáceis

Finalmente contornando isso.

/ lifecycle ativo

@timothysc não foi capaz de replicar em 1.12

root@ip-10-0-0-43:~#  kubeadm join 10.0.0.106:6000 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256:d993ceed705830e8a10fcf2cb29d7c2030217039c6ebafcfb2766dceb45ed885
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.0.0.106:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://10.0.0.106:6000"
[discovery] Requesting info from "https://10.0.0.106:6000" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.0.0.106:6000"
[discovery] Successfully established connection with API Server "10.0.0.106:6000"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "ip-10-0-0-43" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Execute 'kubectl get nodes' no mestre para ver este nó ingressar no cluster.

root@ip-10-0-0-106:~# kubectl get nodes
NAME            STATUS     ROLES    AGE 
ip-10-0-0-106   NotReady   master   3m37s 
ip-10-0-0-43    NotReady   <none>   86s

@rdodev Eu reproduzi na semana passada em 1.12. Por que você acha que o kubeadm está realmente se conectando a 10.0.0.106:6000 ?

regras de firewall @jethrogb . Nas etapas de reprodução que você vinculou, elas estão forçando por meio do iptables.

@jethrogb
`` `
root @ ip-10-0-0-43 : ~ # kubeadm join 10.0.0.106:6443 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c203021704539c6ebcbcfc
[preflight] executando verificações pré-voo
[descoberta] Tentando se conectar ao servidor API "10.0.0.106:6443"
[descoberta] Cliente de descoberta de informações de cluster criado, solicitando informações de " https://10.0.0.106 : 6443"
[descoberta] Falha ao solicitar informações do cluster, tentará novamente: [Obter https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: conectar : Ligação recusada]
[descoberta] Falha ao solicitar informações do cluster, tentará novamente: [Obter https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: conectar : Ligação recusada]
^ C
root @ ip-10-0-0-43 : ~ # kubeadm join 10.0.0.106:6000 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c203021704539c6ebc8827fc
[preflight] executando verificações pré-voo
[descoberta] Tentando se conectar ao servidor API "10.0.0.106:6000"
[descoberta] Cliente de descoberta de informações de cluster criado, solicitando informações de " https://10.0.0.106 : 6000"
[descoberta] Solicitando informações de " https://10.0.0.106 : 6000" novamente para validar o TLS em relação à chave pública fixada
[descoberta] A assinatura e o conteúdo das informações do cluster são válidos e o certificado TLS é validado em relação às raízes fixadas; usará o servidor API "10.0.0.106:6000"
[descoberta] Conexão estabelecida com sucesso com o servidor API "10.0.0.106:6000"
[kubelet] Baixando a configuração do kubelet do ConfigMap "kubelet-config-1.12" no namespace do sistema kube
[kubelet] Gravando a configuração do kubelet no arquivo "/var/lib/kubelet/config.yaml"
[kubelet] Gravando o arquivo de ambiente kubelet com sinalizadores no arquivo "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Ativando o serviço kubelet
[tlsbootstrap] Esperando que o kubelet execute o TLS Bootstrap ...
[patchnode] Fazendo upload das informações do Socket CRI "/var/run/dockershim.sock" para o objeto API do Node "ip-10-0-0-43" como uma anotação

Este nó se juntou ao cluster: `` `

testuser<strong i="5">@ali0</strong>:~$ sudo kubeadm join 10.198.0.221:6443 --token cykhjx.3kabrvhgdkwohqz5 --discovery-token-ca-cert-hash sha256:c2a5e209423b6dd23fe865d0de7a62e42a3638ae40b243885545e4b5152564db --ignore-preflight-errors=SystemVerification
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{} ip_vs:{} ip_vs_rr:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.198.0.221:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.198.0.221:6443"
[discovery] Failed to request cluster info, will try again: [Get https://10.198.0.221:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.198.0.221:6443: connect: connection refused]
^C
testuser<strong i="6">@ali0</strong>:~$ sudo kubeadm join 10.198.0.221:6000 --token cykhjx.3kabrvhgdkwohqz5 --discovery-token-ca-cert-hash sha256:c2a5e209423b6dd23fe865d0de7a62e42a3638ae40b243885545e4b5152564db --ignore-preflight-errors=SystemVerification
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.198.0.221:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://10.198.0.221:6000"
[discovery] Requesting info from "https://10.198.0.221:6000" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.198.0.221:6000"
[discovery] Successfully established connection with API Server "10.198.0.221:6000"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
Get https://10.198.0.221:6443/api/v1/namespaces/kube-system/configmaps/kubelet-config-1.12: dial tcp 10.198.0.221:6443: connect: connection refused

No mestre:

$ sudo KUBECONFIG=/etc/kubernetes/admin.conf kubectl get cm -n kube-public cluster-info -oyaml
apiVersion: v1
data:
  jws-kubeconfig-cykhjx: eyJhbGciOiJIUzI1NiIsImtpZCI6ImN5a2hqeCJ9..BiYLnM2uq2lehUOez8n0tBuMqkErikP0ULsGzyAf_go
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNE1UQXhOakl6TVRNME5sb1hEVEk0TVRBeE16SXpNVE0wTmxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTXNPCkN3OVpVazZJSTVBTjJSUVVyNmRlM1dpMmhOM2hUVSt5aEhCZVMrU0ttQUFPVkp0SmxSTHMwa0c0eXBSb3pENXIKQUphOVRaSi9XOFhLTWdIOUR3ckdHWC9OUzRVRzNoNXdyME5xMlBxeVVqMGZETUNBR2d2MGc3NlNGaTlCWGcrcwoyaEFmOEl5UFlOZ2F1WXFvMUttdjdleXVHUmp2Z2JnU1J2WVIwZWVWYkhxWTIvdlA3T2RBeXRBcytKcGFTS28zCmpVZTR3dGtEcTYralo4ZnlnUS9EbkkwY0pRK1pMaUVIS0d0T2JscnRNWlRxS0RsTXVQd0Y4TE4yQ1kyZUh1WUgKaTM3cUgxMHp1SmlQZXBmOXdVdzc1QkR3eUNlVTVTbUJWUFo0b2xJT3c3ZW5JdDhoNGVpWTlOSklDbHdPNUhDWApaWG0xYmp6L0FKdEhoejg5QXFVQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFBSzlGRkg5eDB0RXhaTGREWjkzQm4walYzTnEKRWl5VzBmUTVpOHBBdlBVV3dMUVd1dkpuM1BLSUtTcjlpZGdwSUthUk1FKzMyRGRXQzVvZDIyakdBQ1REdjBjdAoxbFBSM3RBSTAwQnY2bS9BM09NQVRqY1JKd1hhL0ZHMDdRMU1sbkxibGhXMTlqaVMxQU9ycjRGZ2l1Z3VJQy9uCmd0UWZ3ZHJqTEhZSDY1KzJPRGtnWldNVjBqbjdpZlNMdnlpamJjRUttVXpSZm44T0hmYldWNXRMd2dRN295dHYKRE5tWHdkRkc3WFh3MVZVZjJKQkhDVGJHNndVU1diVFRPbzB1NnJLazJQakZoKzU5QVl4R2I1Ynp4N2thTW8xZwpYZktrUVVWSVcxaGZhelpSUHYzbWEzTmNsSis0R3VIMGc2OThvaEpHZGFkVHpXNmx2WnhoUW9NKzgycz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        server: https://10.198.0.221:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []
kind: ConfigMap
metadata:
  creationTimestamp: 2018-10-16T23:14:15Z
  name: cluster-info
  namespace: kube-public
  resourceVersion: "288"
  selfLink: /api/v1/namespaces/kube-public/configmaps/cluster-info
  uid: 3318106a-d199-11e8-b21c-54e1ad024614

@jethrogb não sabe o que te dizer. Esta é uma instalação de hortelã fresca em infra fresco.

root@ip-10-0-0-106:~# KUBECONFIG=/etc/kubernetes/admin.conf kubectl get cm -n kube-public cluster-info -oyaml apiVersion: v1 data: jws-kubeconfig-nwoa2x: eyJhbGciOiJIUzI1NiIsImtpZCI6Im53b2EyeCJ9..Be2U7ch__XzQ7em8vLEw8WAX6dQZeeLXaKVjh_a7YYA kubeconfig: | apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNE1UQXhOakl5TXpNME4xb1hEVEk0TVRBeE16SXlNek0wTjFvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBS2cxCjREbzhNbGtBSVZJM29xem9XK2trbUtmYjIyOGFLd1FzaXJsSTNMN2F1QnlrWC9JaEk0Tm9UYkZmMFpXbEdkRTYKUlVJNFdUZml1L2RqWXJqZG9YM2pZcGtxRERmTm5KNWxteGkzUStwbmVmM3hTWGtEbTNEOXFadWV0R0JXRTZzRwppNHIycUZxSmRnS21MMCswdnlXNmhkRUNUY1VwdFFTSzkzQmUxTzBMQnFRa1BLd0I0QjQ3Z3d6bGtSOFpaeTAyCm1zN1IvaE9lK0h5NEl2c0FQTmFQbHBpVFhQRyt5d2lLMkoxcXJBb0hzUDhNelNhdzN3OHB4bkJmc2V2NmErYWsKZm42b1p3QVJibi9yTDRNbHJaSlNpWC8vVEdvWTN5YlZYZ2lDWWVzMHNZQWR6T1Q3Sjl2VDBzYkRHK0Z2STFTYQpha05WUDJwdVNkdlhvcmtoc1JFQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEbHJ5eklBRExwbUVEaURxdXhIdURPb2hmS0sKbVhMeVc4SkllYXFzT0k0cGd0aDJITDRJcG4vbm14VWF3bVh4SVB4YWc3N2I1cXZHcm5YTXN6SHd4WUp2SnJ0cgpJU2VyOVdvSmpuY0xVUnhkeTVBb3ZMWFZYZ3Y2S1dHVlFnMkt2dXpmNGMyL1ZVN09jNnpQMlRhNVJJaHgrcVU2CnBSeWN5Q2RJOUdaMUFpN0JSSTd1M3VtUjRiT3BhckpMaVRvZ2hsMGNDTlBDRDBhZ2dlNHBGemxSd0VLbEpINmMKMmgzcGFxZ0dQUU5YY1ZzcGdtbTgvQ2JvbFVta1d1RjZRTm1KemxuK2tUdlhkRTJiY3NkSUxyeU5Nb0J0L2paUQpoaVZxTnhBVWVuV1hEVk8wVnd5ZXRxY3crL2ZGb05jZndUL1FERXduQXpJd29SM3FHdUZXVk1aQllVZz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= server: https://10.0.0.106:6000 name: "" contexts: [] current-context: "" kind: Config preferences: {} users: [] kind: ConfigMap metadata: creationTimestamp: 2018-10-16T22:34:14Z name: cluster-info namespace: kube-public resourceVersion: "314" selfLink: /api/v1/namespaces/kube-public/configmaps/cluster-info uid: 9c0579c2-d193-11e8-b95c-026da1fc2270

@rdodev Esse cluster-info parece que foi modificado do padrão. Usá-lo não irá reproduzir o problema. Qual foi o seu comando kubeadm init ?

kubeadm init --config kudeadm.yaml

root@ip-10-0-0-106:~# cat kudeadm.yaml
apiVersion: kubeadm.k8s.io/v1alpha3
kind: InitConfiguration
apiEndpoint:
  advertiseAddress: "10.0.0.106"
  bindPort: 6000

Então você está inicializando-o com a porta 6000. Isso não vai funcionar para reproduzir este problema. Esse problema é sobre não ser capaz de ingressar com um mestre em um endereço / porta diferente daquele com o qual o mestre foi originalmente configurado.

@jethrogb qual é o caso de uso, por favor. Por que você deseja ingressar em um plano de controle em um endereço / porta diferente daquele com o qual o plano de controle foi colocado online?

Aqui estão alguns ...

1. Endereço IP alterado do mestre.
2. Costumava ter um único mestre, mas agora mudou o mestre para HA. As junções futuras desejarão usar o endereço IP LB
3. O mestre está atrás de um NAT, nem todos os nós usam o mesmo IP para se conectar ao mestre.

O principal problema é que você diz a kubeadm join qual IP / porta usar, ele diz que vai usar aquele endereço, mas não faz !

@jethrogb

No caso 1), você precisa reemitir os certificados de nenhuma outra maneira. Os certificados são gerados para o nome do host e endereço IP do plano de controle no init. Pode ser atenuado emitindo certificados para um nome DNS no init.

No caso 2) o processo de passagem do plano de controle único para HA requer que você emita novamente todos os certificados relevantes (especialmente para adicionar o nome LB dns)

Não tenho certeza 3) é uma configuração com suporte no momento.

Não tenho certeza do que isso tem a ver com certificados.

@jethrogb primeiro, mesmo se você pudesse se conectar (de alguma forma), ele iria falhar na incompatibilidade de certificado, conforme explicado acima.

Em segundo lugar, não é realmente um bug, pois este não é um caso de uso compatível. AFICT não é que antes funcionasse e agora não. Não é apenas um recurso que existe e está quebrado.

@timothysc Não acho que este item e # 598 sejam iguais. Este (# 664) sabemos que funciona porque foi assim que testamos HA em 1.11 e 1.12

598 merece uma olhada como uma solicitação de recurso.

@timothysc ^^

@tallclair haha Eu sabia que isso iria acontecer E_TOO_MANY_TIMS_IN_K8S

@jethrogb primeiro, mesmo se você pudesse se conectar (de alguma forma), ele iria falhar na incompatibilidade de certificado, conforme explicado acima.

Isso não tem nada a ver com certificados. Mesmo se o certificado apresentado pelo servidor API no endereço que o usuário especificou em kubeadm join verificar, kubeadm join irá então (ao contrário de suas afirmações no terminal) se conectar a um endereço totalmente diferente para a última etapa do procedimento de junção.

Em segundo lugar, não é realmente um bug, pois este não é um caso de uso compatível. AFICT não é que antes funcionasse e agora não. Não é apenas um recurso que existe e está quebrado.

Não tenho certeza se entendi o que você está dizendo. Você está dizendo que uma ferramenta de mensagem ao usuário que fará uma coisa enquanto está fazendo outra coisa não é um bug?

Isso não tem nada a ver com certificados. Mesmo se o certificado apresentado pelo servidor API no endereço que o usuário especificou em kubeadm join verificar, kubeadm join irá então (ao contrário de suas afirmações no terminal) se conectar a um endereço totalmente diferente para a última etapa do procedimento de junção.

Para explicar por que os certificados são importantes, vamos ver no caso em que o ip do plano de controle muda, isso acontece:

root@ip-10-0-0-43:~# kubeadm join 34.220.204.xxx:6000 --token nwoa2x.cqar2ndxrtnw9arc 
[preflight] running pre-flight checks
[discovery] Trying to connect to API Server "34.220.204.xxx:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://34.220.204.xxx:6000"
[discovery] Requesting info from "https://34.220.204.xxx:6000" again to validate TLS against the pinned public key
[discovery] Failed to request cluster info, will try again: [Get https://34.220.204.xxx:6000/api/v1/namespaces/kube-public/configmaps/cluster-info: x509: certificate is valid for 10.96.0.1, 10.0.0.106, not 34.220.204.xxx]

O mesmo se aplica ao caso 2) se você estiver indo de um plano de controle único para HA. Apenas tentando apontar os casos de uso que você mencionou acima não são suportados pelo kubeadm w / o re-gerar / swizzling certs nos nós do plano de controle. Portanto, o escopo aqui é apenas para encaminhamento de porta.

Não tenho certeza se entendi o que você está dizendo. Você está dizendo que uma ferramenta de mensagem ao usuário que fará uma coisa enquanto está fazendo outra coisa não é um bug?

Estou pensando que devemos reabrir a discussão de seu problema original porque não é pertinente a este problema específico. Vamos aguardar a entrada de @timothysc sobre como proceder.

@jethrogb Então, se estou lendo isso corretamente, você alterou o ip: port após o init inicial, mas a junção não está usando a substituição da linha de comando, está usando o que foi armazenado no kubeadm conf que está armazenado no cluster.

É um caso de uso estranho, mas os argumentos da linha cmd parecem não estar substituindo @rdodev neste caso de uso. Parece verificar 80-90% do caminho e, em seguida, usar a configuração para a conexão.

Sim, isso é preciso

Pessoal, a interpretação do argumento da linha de comando do terminal do servidor API durante a junção é enganosa. Na verdade, isso é usado apenas durante o bootstrap e para nada mais. E mesmo assim, ele é usado apenas durante a descoberta baseada em token. Ele será ignorado (sem mesmo um único aviso) com a descoberta baseada em kubeconfig.

Portanto, há realmente alguns problemas aqui:

• O endpoint do servidor da API de descoberta baseada em token de bootstrap está tendo uma UX enganosa. Minha melhor aposta é descontinuar a forma de argumento autônomo de fornecer isso e introduzir uma opção de linha de comando descritiva para isso (algo como --discovery-token-apiserver ). O valor fornecido então vai para joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

• Se alguém deseja sobrescrever o servidor API real por nó, talvez tenhamos que modificar a configuração (provavelmente adicionar um campo em NodeRegistrationOptions e / ou possivelmente uma opção de linha de comando?).
  Não persistir tem o potencial de quebrar algo nas execuções subsequentes do kubeadm (como na atualização), portanto, talvez seja necessário armazená-lo como uma anotação também.

• O endpoint do servidor da API de descoberta baseada em token de bootstrap está tendo uma UX enganosa. Minha melhor aposta é descontinuar a forma de argumento autônomo de fornecer isso e introduzir uma opção de linha de comando descritiva para isso (algo como --discovery-token-apiserver ). O valor fornecido então vai para joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

+1

• Se alguém deseja sobrescrever o servidor API real por nó, talvez tenhamos que modificar a configuração (provavelmente adicionar um campo em NodeRegistrationOptions e / ou possivelmente uma opção de linha de comando?).
  Não persistir tem o potencial de quebrar algo nas execuções subsequentes do kubeadm (como na atualização), portanto, talvez seja necessário armazená-lo como uma anotação também.

IMO, não devemos sobrescrever isso no tempo de junção, talvez possamos ter um comando para atualizar o Api Server Endpoint em cluster-info configmap

Eu não estava claro, na verdade. Por "modificar a configuração" eu pretendia realmente adicionar um novo campo em algum lugar no próximo formato de configuração (possivelmente v1beta2 ) e provavelmente persisti-lo em algum lugar do cluster (anotação de nó?).
Porém, isso precisa ser discutido e provavelmente não acontecerá no ciclo atual (especialmente se seguirmos o caminho de "adicionar uma opção de configuração").

O que podemos certamente fazer neste ciclo é adicionar uma opção de linha de comando para o servidor de API de descoberta de token de bootstrap e descontinuar o fornecimento como um argumento anônimo.

@ neolit123 @fabriziopandini WDYT?

O que podemos certamente fazer neste ciclo é adicionar uma opção de linha de comando para o servidor de API de descoberta de token de bootstrap e descontinuar o fornecimento como um argumento anônimo.

Tim e Fabrizio meio que discordaram.
mas estou com +1 por executar a política de suspensão de uso do GA nesse argumento.

não é nada além de problemas.

@ neolit123 mesmo se não formos para a faixa de troca de linha de comando, podemos realmente fazer um trabalho melhor ao documentar o argumento, tanto na ajuda da ferramenta inline ( kubeadm join --help ) e na documentação do site.
Presumo que documentos melhores podem (meio que) "consertar" o problema também e que isso pode ser feito como parte da documentação das fases de junção.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

lendo todo o tíquete, há vários problemas que são mal-entendidos, cobertos em outro lugar ou não documentados.

o problema original:

a edição original fala sobre:

mas kubelet config e kube-proxy config também podem ser master0 ip ou master1 ip, esse comportamento não é esperado em HA.

Eu não entendo esse problema, então se você acha que isso ainda é viável para 1.13 (1.12 não é mais suportado), registre um novo tíquete com todos os detalhes e exemplos.
esse tíquete desviou muito.

o enganoso argumento de junção anônima:

isso foi rastreado aqui:
https://github.com/kubernetes/kubeadm/issues/1375

estávamos planejando mudar para um argumento nomeado para descoberta, por exemplo, --discovery-endpoint mas optou por não aceitar essa ideia e você terá que continuar usando kubeadm join addr:ip

transição de plano de controle único para HA:

foi rastreado aqui:
https://github.com/kubernetes/kubeadm/issues/1664

um PR para este tópico apenas mesclado em nossos documentos:
https://github.com/kubernetes/website/pull/15524

o TL; DR é que se você modificar o endereço do api-server em um nó de plano de controle depois que o cluster for criado, você precisará gerar novamente os certificados e corrigir os objetos do cluster. para uma melhor transição para HA, use nomes DNS.

se houver algo mais em jogo, crie tickets limpos com todos os detalhes para que os mantenedores possam entender o problema.

@ neolit123 # 598 foi mesclado com isso, mas não está claro para mim se foi resolvido.

@jethrogb

598 foi mesclado com este

se o seu problema de # 598 ainda for viável, reabra o problema, mas lembre-se de que ele deve ser reproduzível com 1.13+, porque as versões anteriores estão fora do desvio de suporte e não são suportadas pela equipe do kubeadm.

@ neolit123 Eu tenho um nó de plano de controle do Kubernetes em execução dentro de um contêiner do Docker via https://github.com/kubernetes-sigs/kind. O servidor API é exposto no host Docker por meio de encaminhamento de porta. Preciso adicionar um nó de trabalho na rede do host Docker para o cluster.

Obviamente, o endereço IP e o nome do host do contêiner executando o kubelet e o host Docker em que a API é exposta por meio de encaminhamento de porta são diferentes, portanto, encontramos os problemas descritos nesta edição. Por um lado, quando alguém atinge a API do nó mestre por meio da porta encaminhada no host Docker, o endereço IP não corresponde ao certificado. Isso é fácil de consertar: podemos apenas adicionar o IP do host Docker a CertificateSANs ao usar kubeadm para implantar o cluster.

O outro problema (que é mais difícil de resolver) é que quando tentamos juntar o nó de trabalho ao cluster, precisamos substituir consistentemente o endpoint da API que está sendo usado para alcançar o nó mestre (ou seja, ele deve usar o IP do host Docker em todos os lugares, e não o endereço IP interno do contêiner Docker, ao qual ele não tem acesso).

Pelo que eu entendo, ainda não há maneira de fazer isso, ou pelo menos não consigo ver uma só de olhar para as sinalizações de kubeadm join e fazer oO argumento de posição serve a esse propósito é o que essa questão estava pedindo (admito que não entendi totalmente o contra-argumento contra isso). Estou esquecendo de algo?

O outro problema (que é mais difícil de resolver) é que quando tentamos juntar o nó de trabalho ao cluster, precisamos substituir consistentemente o endpoint da API que está sendo usado para alcançar o nó mestre (ou seja, ele deve usar o IP do host Docker em todos os lugares, e não o endereço IP interno do contêiner Docker, ao qual ele não tem acesso).

este parece ser um cenário sem suporte por tipo.
você recebeu feedback dos mantenedores gentis (ou #kind no slack k8s)?

Pelo que entendi, ainda não há maneira de fazer isso, ou pelo menos não consigo ver olhando para os sinalizadores de junção do kubeadm e fazendo com que o argumento host: port position servir a esse propósito é o que esse problema estava pedindo ( admito que não compreendi totalmente o contra-argumento contra isto). Estou esquecendo de algo?

o OP desta edição estava confuso e não acho que esteja relacionado ao seu problema.

@ neolit123 A questão importante é se é um cenário suportado pelo kubeadm; kind envolve apenas o kubeadm e um tempo de execução do contêiner. Posso pensar em vários outros cenários que não envolvem o tipo em que a porta da API do nó do plano de controle do kubernetes é encaminhada para outro lugar e o nó do trabalhador deve ser registrado em uma rede onde o endereço do plano de controle original não está acessível. Por exemplo, usando um túnel SSH ou um proxy reverso TCP.

kubeadm join precisa de um endpoint kube-apiserver para realizar a descoberta e o bootstrap do nó.
aquele kube-apiserver pode estar em qualquer lugar - na mesma rede ou em outra rede e o kubeadm suporta esses casos.
o ponto de extremidade também pode ser um ponto de extremidade do balanceador de carga.

esse endpoint é então escrito em um arquivo kubelet.conf do nó de trabalho que é usado para se comunicar com o servidor de API

você pode omitir o argumento posicional completamente de kubeadm join e usar o campo de descoberta de JoinConfiguration .

O outro problema (que é mais difícil de resolver) é que quando tentamos juntar o nó de trabalho ao cluster, precisamos substituir consistentemente o endpoint da API que está sendo usado para alcançar o nó mestre (ou seja, ele deve usar o IP do host Docker em todos os lugares, e não o endereço IP interno do contêiner Docker, ao qual ele não tem acesso).

isso parece ser um problema do software de alto nível que usa kubeadm (por exemplo, kind).
o software de alto nível não está executando kubeadm join com o endpoint que você deseja.

A questão importante é se é um cenário suportado pelo kubeadm; kind envolve apenas o kubeadm e um tempo de execução do contêiner. Posso pensar em vários outros cenários que não envolvem o tipo em que a porta da API do nó do plano de controle do kubernetes é encaminhada para outro lugar e o nó do trabalhador deve ser registrado em uma rede onde o endereço do plano de controle original não está acessível. Por exemplo, usando um túnel SSH ou um proxy reverso TCP.

se um kube-apiserver não estiver acessível, o kubeadm não poderá unir esse novo nó ao cluster. período.
kubeadm join precisa de um endpoint válido ao qual um cliente k8s possa se conectar para realizar a descoberta e validação, o que levaria ao bootstrap de TLS e à criação de um novo objeto Node.

então, sim, kubeadm join precisa de um endpoint de servidor de API válido / acessível.

o software de alto nível não está executando o kubeadm join com o endpoint que você deseja.

Não é kind que está executando kubeadm join , sou eu. Estou executando kubeadm join manualmente, fornecendo o endereço do host Docker onde a API é exposta por meio de encaminhamento de porta (observe que isso não corresponde ao --control-plane-endpoint que foi usado para iniciar o nó do plano de controle próprio; esse endereço não está acessível ao nó do trabalhador).

O problema é que o endereço que forneço para kubeadm join não é usado de forma consistente em todo o processo de junção: ele é usado apenas nos estágios iniciais, após o que o processo falha porque em algum ponto o nó de trabalho baixa a configuração do API do plano de controle e, em seguida, começa a usar o endereço original inacessível correspondente ao argumento --control-plane-endpoint que foi usado para iniciar o nó do plano de controle.

se um kube-apiserver não estiver acessível, o kubeadm não poderá unir esse novo nó ao cluster. período.

O kube-apiserver pode ser acessado por meio de encaminhamento de porta . Não é acessível no endereço original que foi especificado usando --advertise-addr ou --control-plane-endpoint quando kubeadm init foi usado, porque esse endereço é uma função da rede na qual o nó do plano de controle em si está sendo executado, e não necessariamente da rede na qual o trabalhador ingressante está executando.

registre um problema separado e forneça endereços IP e exemplos concretos de sua configuração.

@ neolit123 não está claro para mim por que outro problema é necessário. Esse problema já foi relatado várias vezes nos últimos anos e é o mesmo problema todas as vezes: você executa kubeadm join ADDRESS e em algum ponto ADDRESS (que funciona) é trocado por outra coisa ( que não funciona).

vamos começar em uma nova edição para ver:

• as etapas de reprodução mínimas precisas.
• versões afetadas do kubeadm.

versões afetadas do kubeadm.

na verdade, eu ficaria muito curioso sobre o acima, porque olhando nossa lógica para 1.17 e 1.18 em:
https://github.com/kubernetes/kubernetes/tree/release-1.17/cmd/kubeadm/app/discovery
https://github.com/kubernetes/kubernetes/tree/release-1.18/cmd/kubeadm/app/discovery

o endpoint que você alimenta como argumento posicional ou via JoinConfiguration termina no bootstrap-kubelet.conf validado que está escrito no disco.