Kubeadm: adicionar suporte para o OpenRC como sistema init

Corrija primeiro os avisos que o kubeadm está fornecendo a você. Por exemplo, comece definindo o valor adequado para a variável de ambiente NO_PROXY, então certifique-se de que todos os binários necessários estão presentes no sistema (tc, ebtables, ...) e então verifique o que está no status e nos logs do kubelet.

/atribuir

Com todos os avisos além de não ter um sistema init compatível detectado. Ainda tem o mesmo problema.

kubeadm init
I1204 10: 42: 06.894219 7292 version.go: 236] versão remota é muito mais recente: v1.13.0; caindo de volta para: estável-1.12
[init] usando Kubernetes versão: v1.12.3
[preflight] executando verificações pré-voo
[AVISO Firewalld]: nenhum sistema init compatível detectado, ignorando a verificação de serviços
[WARNING Service-Docker]: nenhum sistema init compatível detectado, ignorando a verificação de serviços
[AVISO Service-Kubelet]: nenhum sistema init compatível detectado, ignorando a verificação de serviços
[preflight / images] Extração de imagens necessárias para configurar um cluster Kubernetes
[preflight / imagens] Isso pode levar um ou dois minutos, dependendo da velocidade de sua conexão de internet
[preflight / images] Você também pode executar esta ação com antecedência usando 'kubeadm config images pull'
[preflight] nenhum sistema init suportado detectado, não garantirá que o kubelet não seja executado por um curto período de tempo ao definir a configuração para ele.
[kubelet] Gravando o arquivo de ambiente kubelet com sinalizadores no arquivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Gravando a configuração do kubelet no arquivo "/var/lib/kubelet/config.yaml"
[preflight] nenhum sistema init compatível detectado, não garantirá que o kubelet esteja funcionando corretamente.
[certificados] Usando o certificado e a chave etcd / servidor existentes.
[certificados] Usando o certificado e a chave apiserver-etcd-client existentes.
[certificados] Usando o certificado e chave etcd / peer existentes.
[certificados] Usando o certificado e a chave etcd / healthcheck-client existentes.
[certificados] Usando o certificado e a chave apiserver existentes.
[certificados] Usando o certificado e a chave existentes do apiserver-kubelet-client.
[certificados] Usando o certificado e a chave do cliente proxy existente.
[certificados] certificados e chaves válidos agora existem em "/ etc / kubernetes / pki"
[certificados] Usando a chave sa existente.
[kubeconfig] Usando o arquivo KubeConfig atualizado existente: "/etc/kubernetes/admin.conf"
[kubeconfig] Usando o arquivo KubeConfig atualizado existente: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Usando o arquivo KubeConfig atualizado existente: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Usando o arquivo KubeConfig atualizado existente: "/etc/kubernetes/scheduler.conf"
[controlplane] escreveu o manifesto do pod estático para o componente kube-apiserver em "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] escreveu o manifesto do pod estático para o componente kube-controller-manager em "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] escreveu o manifesto do pod estático para o componente kube-scheduler em "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Escreveu o manifesto do pod estático para uma instância local do etcd em "/etc/kubernetes/manifests/etcd.yaml"
[init] esperando que o kubelet inicialize o plano de controle como pods estáticos do diretório "/ etc / kubernetes / manifests"
[init] isso pode levar um minuto ou mais se as imagens do plano de controle tiverem que ser puxadas
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] A chamada HTTP igual a 'curl -sSL http: // localhost : 10248 / healthz' falhou com o erro: Get http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: conectar : Ligação recusada.

Infelizmente, ocorreu um erro:
expirou o tempo de espera pela condição

Este erro é provavelmente causado por:
- O kubelet não está funcionando
- O kubelet não está íntegro devido a uma configuração incorreta do nó de alguma forma (cgroups obrigatórios desativados)

Se você estiver em um sistema com base em systemd, poderá tentar solucionar o erro com os seguintes comandos:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Além disso, um componente do plano de controle pode ter travado ou saído quando iniciado pelo tempo de execução do contêiner.
Para solucionar o problema, liste todos os contêineres usando seus tempos de execução de contêiner preferidos CLI, por exemplo, docker.
Aqui está um exemplo de como você pode listar todos os contêineres do Kubernetes em execução no docker:
- 'docker ps -a | grep kube | grep -v pause '
Depois de encontrar o contêiner com falha, você pode inspecionar seus registros com:
- 'docker logs CONTAINERID'
não foi possível inicializar um cluster Kubernetes

Também não suportar o sistema init (openrc) é totalmente compreensível, talvez uma melhoria aqui seja apenas alguma documentação dos sistemas init suportados (ou apenas dizendo que ele só suporta systemd se for o caso)

Você pode compartilhar o que está nos registros do kubelet e nos contêineres do docker (se houver algum em execução após as mensagens de erro do kubeadm)

Oi kad, pelo que eu posso dizer, não há nenhum processo kubelet em execução e nenhum contêiner foi iniciado.

Eu sei pouco sobre o interno do kubeadms, mas parece que ele deseja configurar um serviço no início (por exemplo, systemd), não consegue encontrar um sistema init compatível, então pula, mas mais tarde está esperando que o sistema init inicie o kubelet.

ps
COMANDO DE TEMPO DO USUÁRIO PID
1 root 0:00 / sbin / init
2 root 0:00 [kthreadd]
4 root 0:00 [kworker / 0: 0H]
5 root 0:00 [kworker / u64: 0]
6 root 0:00 [mm_percpu_wq]
7 root 0:00 [ksoftirqd / 0]
8 root 0:00 [rcu_sched]
9 root 0:00 [rcu_bh]
10 root 0:00 [migração / 0]
11 root 0:00 [watchdog / 0]
12 root 0:00 [cpuhp / 0]
13 root 0:00 [kdevtmpfs]
14 root 0:00 [netns]
16 root 0:00 [oom_reaper]
174 root 0:00 [write-back]
175 root 0:00 [kworker / 0: 1]
176 root 0:00 [kcompactd0]
178 root 0:00 [ksmd]
179 root 0:00 [cripto]
180 root 0:00 [kintegrityd]
182 root 0:00 [kblockd]
445 root 0:00 [ata_sff]
454 root 0:00 [md]
460 root 0:00 [watchdogd]
585 root 0:00 [kauditd]
591 root 0:00 [kswapd0]
679 root 0:00 [kthrotld]
911 root 0:00 [hv_vmbus_con]
1182 root 0:00 [scsi_eh_0]
1255 root 0:00 [scsi_tmf_0]
1264 root 0:00 [kworker / u64: 3]
1406 root 0:00 [jbd2 / sda3-8]
1407 root 0:00 [ext4-rsv-conver]
1821 root 0:00 [hv_balloon]
1874 root 0:00 [ipv6_addrconf]
1965 root 0:00 [kworker / 0: 1H]
2235 root 0:00 / sbin / syslogd -Z
2289 root 0:00 / sbin / acpid
2318 chrony 0:00 / usr / sbin / chronyd -f /etc/chrony/chrony.conf
2345 root 0:00 / usr / sbin / crond -c / etc / crontabs
2447 root 0:06 / usr / bin / dockerd -p /run/docker.pid
2480 root 0:00 / usr / sbin / sshd
2485 root 0:00 / sbin / getty 38400 tty1
2486 root 0:00 / sbin / getty 38400 tty2
2489 root 0:00 / sbin / getty 38400 tty3
2491 root 0:00 / sbin / getty 38400 tty4
2495 root 0:00 / sbin / getty 38400 tty5
2498 root 0:00 / sbin / getty 38400 tty6
2507 root 0:00 sshd: root @ pts / 0
2509 root 0:00 -ash
2514 root 0:00 docker-containerd --config /var/run/docker/containerd/containerd.toml
2964 root 0:00 [kworker / 0: 0]
3064 root 0:00 sshd: root @ pts / 1
3066 root 0:00 -ash
3241 root 0:00 [kworker / u64: 1]
3311 root 0:00 [kworker / 0: 2]
3314 root 0:00 / sbin / getty -L 115200 ttyS0 vt100
3315 root 0:00 ps

docker ps -a
COMANDO DE IMAGEM DE ID DE CONTÊINER CRIADO NOMES DE PORTOS DE STATUS

suporta apenas sistema init systemd e wininit. você poderia instalar o kubelet manualmente e excluir o código de instalação do arquivo de configuração do kubelet no kubeadm, mybe, isso funciona

o linux alpino é um alvo para nós?
podemos contar com a comunidade para corrigi-lo.

o linux alpino é um alvo para nós?
podemos contar com a comunidade para corrigi-lo.

Alpine Linux é um destino muito popular para contêineres - devido ao seu tamanho / instalação extremamente pequeno - também bastante popular para Vagrant / EC2 - estou surpreso por não ser compatível. Grepped através do código kubedm - parece que ele está apenas bagunçando o systemd para iniciar o docker / kubernetes

Existe um documento que descreve o que o kubeadm faz / pretende fazer / depende do sistema init?

Existe um documento que descreve o que o kubeadm faz / pretende fazer / depende do sistema init

no Linux, ele usa o systemd para iniciar / parar o kubelet:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

este documento descreve parcialmente a interação kubeadm / systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelets-using-kubeadm

https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System

Alpine Linux usa OpenRC para seu sistema init.

este sistema init não é compatível com os kubernetes principais.
neste caso, o kubeadm usa o que está disponível no núcleo.

[WARNING Service-Docker]: nenhum sistema init compatível detectado, ignorando a verificação de serviços
[AVISO Service-Kubelet]: nenhum sistema init compatível detectado, ignorando a verificação de serviços

isso vem daqui:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
e novos sistemas init devem ser adicionados lá.

/ assign @timothysc @detiber
para julgamento sobre este.

Alguém já empacotou os binários necessários (e os scripts de inicialização necessários) para o Alpine? Nesse caso, não vejo um problema em adicionar suporte adequado para gerenciar os serviços corretamente. Se não, eu consideraria isso um pré-requisito para que isso continuasse, uma vez que o gerenciamento de scripts / config de inicialização não é responsabilidade do kubeadm.

Parece haver um único pacote kubernetes aqui .

@rosti Olhando para o conteúdo desse pacote, basicamente parece um despejo de vários binários k8s e não inclui um script de inicialização ou configuração necessária para ser conduzido pelo kubeadm.

Normalmente sou um espreitador. Mas há interesse da indústria no Kubernetes on the Edge usando ARM e várias opções de bare metal estão sendo investigadas, com a Alpine sendo uma mistura de opções de sistema operacional.

Acho que o suporte do OpenRC no kubeadm é um tipo de must-have, não tenho certeza se a comunidade Alpine vai apresentar um patch que 'corrige' algo tão fundamental para a fama do sistema operacional.

Normalmente sou um espreitador. Mas há interesse da indústria no Kubernetes on the Edge usando ARM e várias opções de bare metal estão sendo investigadas, com a Alpine sendo uma mistura de opções de sistema operacional.

Acho que o suporte do OpenRC no kubeadm é um tipo de must-have, não tenho certeza se a comunidade Alpine vai apresentar um patch que 'corrige' algo tão fundamental para a fama do sistema operacional.

Eu suspeito fortemente que você está correto - com o tamanho da memória / imagem que eles têm como alvo - eu realmente não consigo imaginá-los seguindo (sem desrespeito) a rota do systemd.

Existe um documento que descreve o que o kubeadm faz / pretende fazer / depende do sistema init

no Linux, ele usa o systemd para iniciar / parar o kubelet:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

este documento descreve parcialmente a interação kubeadm / systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelets-using-kubeadm

https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System

Alpine Linux usa OpenRC para seu sistema init.

este sistema init não é compatível com os kubernetes principais.
neste caso, o kubeadm usa o que está disponível no núcleo.

[WARNING Service-Docker]: nenhum sistema init compatível detectado, ignorando a verificação de serviços
[AVISO Service-Kubelet]: nenhum sistema init compatível detectado, ignorando a verificação de serviços

isso vem daqui:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
e novos sistemas init devem ser adicionados lá.

À primeira vista, isso parece bastante simples. Não sou aficionado por Go de forma alguma, mas parece que estou apenas fazendo chamadas diretas para um shell. Adicionar outro implementador a essa interface InitSystem que funciona para OpenRC mais o script de serviço openrc provavelmente resolveria.

EDITAR:
Mergulhar e colocar o Kubernetes no Alpine-ARM vai exigir algum trabalho. Executar o kubelet manualmente é possível, mas após um tempo significativo de depuração, suspeito que há um problema de rede em andamento, pois o apiserver está falhando ao sincronizar com o etcd ao fazer uma inicialização básica com o kubeadm.

@detiber você está correto aí. Mas algum pacote é melhor do que nenhum. Isso significa que temos um mantenedor que podemos enviar com uma proposta específica.

@bcdurden

isso vem daqui:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
e novos sistemas init devem ser adicionados lá.

À primeira vista, isso parece bastante simples. Não sou aficionado por Go de forma alguma, mas parece que estou apenas fazendo chamadas diretas para um shell. Adicionar outro implementador a essa interface InitSystem que funciona para OpenRC mais o script de serviço openrc provavelmente resolveria.

sim, contribuições são bem-vindas - isto é, este esforço é conduzido pela comunidade. quem mandar um PR para isso, por favor me ping

RE: pacotes.

ping @fcolista
conforme: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

existem planos para continuar a manter este pacote?
parece não ter integração com o sistema init e incluir apenas binários.

estamos discutindo sobre o suporte potencial para Alpine Linux no kubeadm.
o bloqueador principal aqui não está realmente no lado do kubeadm, mas sim no núcleo dos kubernetes que não têm suporte para OpenRC (consulte o comentário acima).

RE: pacotes.

ping @fcolista
conforme: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

existem planos para continuar a manter este pacote?
parece não ter integração com o sistema init e incluir apenas binários.

estamos discutindo sobre o suporte potencial para Alpine Linux no kubeadm.
o bloqueador principal aqui não está realmente no lado do kubeadm, mas sim no núcleo dos kubernetes que não têm suporte para OpenRC (consulte o comentário acima).

Para sua informação, há um pacote kubernetes-cni correspondente, bem feito pelo mesmo contribuidor; mas tem os mesmos problemas (sem inicialização ou configuração dos artefatos no apk).

RE: pacotes.

ping @fcolista
conforme: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

existem planos para continuar a manter este pacote?
parece não ter integração com o sistema init e incluir apenas binários.

estamos discutindo sobre o suporte potencial para Alpine Linux no kubeadm.
o bloqueador principal aqui não está realmente no lado do kubeadm, mas sim no núcleo dos kubernetes que não têm suporte para OpenRC (consulte o comentário acima).

@ neolit123 , @bcdurden hi.
Sinta-se à vontade para abrir um PR em https://github.com/alpinelinux/aports/ com um init openrc.
Eu tentei construir kubernetes 1.13.2, mas a compilação está sem memória no momento.
Eu não uso o kubernetes, então se você tiver alguma dica sobre como testar rapidamente um possível init que seria muito apreciado, posso trabalhar nisso. Ao mesmo tempo, o pacote está em "teste" prontamente pelo motivo de não estar pronto para produção.
Obrigado!

@fcolista Eu tenho um, mas é 'hacky'. Algo sobre Alpine em ARM64 com Kubelet bloqueia o etcd de ser concluído ou não espera o tempo suficiente. Tenho que iniciar o kubelet, eliminar o processo após cerca de 20-30s e reiniciá-lo novamente. Não parece estar esperando o tempo suficiente para permitir que apiserver fique online e crie / sincronize recursos (leva cerca de 2 minutos no total). Esse truque torna o uso do kubeadm init e join bastante arriscado. Não tive a chance de rastrear o problema. Este é o Alpine 3.8 em ARM64 em execução em RPi 3B +

Eu também encontrei outro problema com o kubeadm join com problemas com o binário 'find' do BusyBox sem o sinalizador -printf.

EDIT: Esqueci de adicionar, isso está usando os binários de lançamento geral do Kubernetes para ARM64. Definitivamente, não estou compilando (Go é apenas um pacote Edge para 3.8 em terreno ARM64)

@bcdurden isso é muito interessante. Pode ser que o etcd não esteja girando rápido o suficiente e o servidor da API entre em um loop de falha (semelhante a kubernetes / kubernetes # 72984).
Podemos ver o resultado de docker ps -a e alguns dos logs do kubelet?

@bcdurden isso é muito interessante. Pode ser que o etcd não esteja girando rápido o suficiente e o servidor de API entre em um loop de falha (semelhante a kubernetes / kubernetes # 72984 ).
Podemos ver o resultado de docker ps -a e alguns dos logs do kubelet?

@rosti É bem possível, embora eu me lembre de que parece que o etcd está em execução e ouvindo ativamente as solicitações. Não é apenas recebê-los ou processá-los? Chega um ponto onde o apiserver diz 'Carregando controladores' e lista os vários tipos que ele suporta, etc. E então nunca chega ao ponto onde sincroniza os recursos corretamente. Eventualmente, ele apresenta uma mensagem de falha que descreve a impossibilidade de sincronizar recursos. Kubelet então reinicia o apiserver e tenta novamente (um loop infinito neste ponto).

No momento, estou em viagem de negócios, mas tentarei obter os registros aqui assim que puder.

Até que isso seja resolvido, criei este https://github.com/oz123/systemctl-shim/ para traduzir os comandos systemctl para o openrc.

estamos atualmente congelando o código para 1.14, mas o https://github.com/kubernetes/kubernetes/pull/73101 PR parece uma fusão limpa para mim. está bloqueado em pkg/util/initsystem/ OWNERS e, com sorte, podemos mesclá-lo em breve.

^ pingado pessoas sobre o PR acima.

@ oz123 @btrepp et al,
LMK se mesclar https://github.com/kubernetes/kubernetes/pull/73101 desbloqueia usuários alpinos.

@ neolit123 obrigado por cuidar. Vou continuar o trabalho agora. Isso é incrível!

@ oz123 poderia descrever o que mais deve ser feito?

@ neolit123 é necessário verificar se as falhas no OpenRC não geram a mensagem:

If you are on a systemd-powered system, you can try ....

veja por exemplo kubeletFailTempl .

Além disso, os sinalizadores do kubelet são gravados em / etc / places, o que não faz sentido para o OpenRC e são relevantes apenas para o systemd. Então, isso também precisa ser modular ...
Não consegui. Posso enviar uma grande solicitação de mesclagem para resolver todos os problemas de uma vez. Pretendo dividir o trabalho em cerca de 2 a 3 mais PRs. Portanto, o problema deve ser reaberto, ou podemos rastrear isso em outro problema.

ok, obrigado por refrescar minha memória. estou começando a me lembrar do que precisava ser feito.

Além disso, os sinalizadores do kubelet são gravados em / etc / places, o que não faz sentido para o OpenRC e são relevantes apenas para o systemd. Então, isso também precisa ser modular ...

de preferência, as mudanças devem ser bem abstraídas no tempo de execução e não muito intrusivas às formas já existentes de lidar com o sistema init. isso é principalmente devido ao systemd ser o alvo principal.

eu começaria com uma função de utilidade que detecta openrc possivelmente em cmd/kubeadm/app/util/initsystem
ele deve ter um teste de unidade e ser autônomo no Windows.

apenas me mande um ping em qualquer PRs.

@ neolit123 a detecção do sistema init é feita corretamente já em
cmd/kubeadm/app/phases/kubelet/kubelet.go , então não acho que haja necessidade de outro arquivo.

hm, ele irá abstrair o processo de início / parada do serviço, mas o kubeadm ainda irá ler / gravar alguns arquivos, como o arquivo drop-in dinâmico em / etc. o resto do código também precisa saber sobre o openrc:
por exemplo
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/flags.go#L120

O arquivo drop-in kubelet para systemd
https://kubernetes.io/docs/setup/independent/kubelet-integration/#the -kubelet-drop-in-file-for-systemd

Exatamente, eu disse acima que o kubeadm grava coisas no sistema de arquivos em locais que são relevantes apenas para o system.
Ok, então farei o trabalho necessário conforme você sugeriu em cmd/kubeadm/app/util/initsystem .

https://github.com/oz123/kubernetes/blob/2a40ef473f906b6a165690480dc000b9e5560258/pkg/util/initsystem/initsystem.go
^ se isso incluísse um método para retornar o tipo de enum do sistema init detectado, teria sido ainda mais limpo, mas como você viu, a fusão de PRs pode demorar um pouco ...

Deve ser marcado lifecycle/active ou desmarcado help wanted ? Não parece pronto para ninguém pegar, uma vez que já está sendo trabalhado.

marcado como ativo como @ oz123 mencionou que pode consultar as alterações

Visto que o PR acima menciona suporte parcial, o que está faltando no momento para suporte total @ oz123 ?

@mrueg o que está faltando é quase tudo que discutimos neste tópico. Atualmente não tenho tempo para concluir o trabalho, se alguém quiser patrociná-lo sinta-se à vontade para entrar em contato comigo. Se outra pessoa quiser assumir este trabalho, também estou bem com isso.

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

/ ciclo de vida congelado

este é um problema pendente de openrc: https://github.com/kubernetes/kubeadm/issues/1986

incapaz de correr em alpino também :(

Estou usando o k8s no Alpine (um único cluster em execução em x86_64, armv7 e aarch64) como uma solução alternativa ao unir um nó a um cluster. Reinicio manualmente o kubelet quando ele falha, parece ser necessário fazer apenas uma vez.

Consegui iniciar um cluster outro dia com a ajuda de @ neolit123 .

• Este PR https://github.com/kubernetes/kubernetes/pull/90892 corrige o travamento do kubeadm
• Havia outro problema com resolv-conf padronizado para /run/systemd/resolve/resolv.conf , eu havia preparado outro commit porque estava atrás do mestre, mas aparentemente isso foi corrigido em https://github.com/kubernetes/kubernetes / commit / 28b9a4e0d64e3a00343a93e1fc241a5328c3f926 # diff -1a4e0bdeb8495d00560f3e20354abf41

Além disso, para completar isso, preciso de alguma cooperação de @fcolista para consertar o lado alpino das coisas. Já entrei em contato com você, mas não obtive resposta.

Caso contrário, tudo do lado kubeadm funciona bem agora e este problema pode ser resolvido assim que meu PR for mesclado.

@xphoniex Estou disponível para ajudar.
Eu prefiro que seu patch seja aplicado upstream ... no momento a versão Alpine está travada em 1.17.3, já que 1.18 não é compilado com go 1.13.
Deixe-me saber que tipo de ajuda / cooperação você precisa da minha parte.
Obrigado!

Esses PRs no lado alpino são necessários, deixando-os aqui para referência:

• adicione pidfile a docker.initd e crie sua pasta

• corrigir o problema do serviço kubelet na inicialização, adicionar suporte para kubeadm

• alterar a localização dos binários e licença dos plug-ins cni

E é isso.

@xphoniex eles foram mesclados
.: Francesco

podemos fechar também agora que https://github.com/kubernetes/kubernetes/pull/90892 foi mesclado @ neolit123 , sim?

acho que este é o último item restante:
https://github.com/kubernetes/kubeadm/issues/1295#issuecomment -491446853

A Alpine já usa /etc/ para serviços, então mantivemos os arquivos de configuração lá também.

Nós apenas tivemos que atualizar os sinalizadores em kubelet.confd e kubelet.initd para o pacote kubernetes para permitir que o OpenRC soubesse onde o resto dos arquivos de configuração estavam, você pode ver a diferença aqui .

Observe, por exemplo, que fizemos --cni-bin-dir=/usr/share/cni-plugins/bin acordo com a sugestão de Francesco, enquanto em outras distros esperamos que os binários estejam em /opt/cni/bin .

entendido, esta é uma ótima notícia e vou fechar este ticket (finalmente).
/perto

alguns arquivos de serviço FYI WRT:

• a atualização para o arquivo 10-kubeadm.conf é iminente neste ponto, mas não está claro quando , talvez em +3, talvez +5 versões.
  o kubelet está removendo todos os seus sinalizadores em favor de usar os valores do arquivo de configuração via --config. quando isso acontecer, vamos parar de terceirizar kubeadm-flags.env e /etc/default/kubelet em 10-kubeadm.conf e o kubeadm irá parar de gerar kubeadm-flags.env no tempo de execução.

• dockershim, que é a implementação CRI para docker, está saindo do código-fonte do kubelet para um repositório git separado e um serviço separado. portanto, os usuários do docker terão que executá-lo separadamente antes de iniciar o serviço kubelet. não está claro qual é a base de usuários do docker no alpine, mas o docker geral para os usuários do kubeadm é de 70%, de acordo com uma pesquisa que fizemos alguns anos atrás.

@ neolit123 : Fechando este problema.