Observe que provavelmente também devemos renomear o serviço para lbservice ou algo assim para diferenciá-los de outros tipos de serviços.

Como parte disso, eu removeria objetos de serviço do apiserver principal e facilitaria o uso de outros balanceadores de carga, como HAProxy e nginx.

Seria bom se a definição lógica de um serviço (a consulta e / ou nome global) pudesse ser usada / especializada de várias maneiras - como um balanceador de carga simples instalado por meio da infraestrutura, como um balanceador de carga completo de recursos como nginx ou haproxy também oferecido pela infraestrutura, como um endpoint consultável em que um integrador pode pesquisar / esperar (GET / services / foo -> {endpoints: [{host, port}, ...]}), ou como informações disponíveis para hosts para expor balanceadores de carga locais. Obviamente, esses podem ser vários casos de uso diferentes e, como tal, divididos em seus próprios recursos, mas ter alguma flexibilidade para especificar a intenção (unificar sob um lb) distinta do mecanismo torna mais fácil satisfazer uma ampla gama de requisitos.

@smarterclayton Eu concordo em separar política e mecanismo.

Precisamos de primitivos:

1. A capacidade de pesquisar / assistir a um conjunto identificado por um seletor de rótulo. Não tenho certeza se há um problema arquivado ainda.
2. A capacidade de consultar endereços IP de pod (# 385).

Isso seria o suficiente para compor com outros mecanismos de nomenclatura / descoberta e / ou balanceadores de carga. Poderíamos então construir uma camada de nível superior no topo do núcleo que agrupa padrões comuns com uma API simples.

Vale a pena manter esse problema aberto nas duas primitivas descritas por @ bgrant0607 ? Ou existem questões mais específicas que podemos apresentar?

Não acho que o zookeeper esteja resolvido - já que você precisa do identificador exclusivo em cada contêiner. _Acho_ que você poderia fazer isso com 3 controladores de replicação separados (um por instância) ou um modo no controlador de replicação.

Acho que o design do serviço merece alguma discussão, como observa o Brian. Atualmente ele acopla uma abstração de infraestrutura (proxy local) com um mecanismo de exposição (variáveis ​​de ambiente em todos os contêineres) com uma consulta de rótulo. Há um caso de uso igualmente válido para um proxy de borda que pega hosts / caminhos L7 e os equilibra para uma consulta de rótulo, bem como protocolos de suporte como http (s) e web sockets. Além disso, os serviços têm hoje um limite de escala rígido de 60 mil back-ends, compartilhados por todo o cluster (a quantidade de IPs alocados). Deve ser possível executar um proxy local em um minion que faz proxy apenas dos serviços de que os contêineres naquele host precisam e também para evitar que os contêineres precisem saber sobre a porta externa. Podemos mover esta discussão para # 494 se necessário.

Lidar com o problema de serviços singleton e serviços não escalonados automaticamente com replicação fixa, como bancos de dados replicados mestre-escravo, armazenamentos de valores-chave com grupos de pares de tamanho fixo (por exemplo, etcd, zookeeper), etc.

Os casos de replicação fixa requerem um comportamento previsível do tipo array. Os pares precisam ser capazes de descobrir e se dirigir individualmente. Esses serviços geralmente têm suas próprias bibliotecas de cliente e / ou protocolos, portanto, não precisamos resolver o problema de determinar a qual instância um cliente deve se conectar, a não ser para tornar as instâncias endereçáveis ​​individualmente.

Proposta: Devemos criar um novo tipo de serviço, chamado de serviços Cardinal, que mapeia N endereços IP em vez de apenas um. Os serviços Cardinal executariam uma atribuição estável desses endereços IP a N instâncias direcionadas por seu seletor de rótulo (ou seja, um N especificado, não apenas quantos destinos existam). Assim que tivermos o DNS (# 1261, # 146), ele atribuirá nomes DNS previsíveis com base em um prefixo fornecido, com sufixos de 0 a N-1. As atribuições podem ser registradas em anotações ou rótulos dos pods de destino.

Isso preservaria o desacoplamento da atribuição de função das identidades dos pods e controladores de replicação, ao mesmo tempo que forneceria nomes e endereços IP estáveis, que poderiam ser usados ​​em mecanismos de configuração de aplicativo padrão.

Algumas das discussões sobre os diferentes tipos de balanceamento de carga aconteceram no design dos serviços v2: # 1107.

Apresentarei uma questão separada para a eleição do mestre.

/ cc @smarterclayton @thockin

As atribuições teriam que ser realizadas nos pods por meio de algum mecanismo de parametrização de ambiente (quase certamente).

Para o exemplo do etcd, eu criaria:

• Cardinalidade do controlador de replicação 1: 1 pod, apontando para o volume A de armazenamento estável
• cardinalidade do controlador de replicação 2: 1 pod, apontando para o volume de armazenamento estável B
• Cardinalidade do controlador de replicação 3: 1 pod, apontando para o volume C de armazenamento estável
• serviço cardinal 'etcd' apontando para os pods

Se o pod 2 morrer, o controlador de replicação 2 criará uma nova cópia dele e a reconectará ao volume B. O serviço cardinal 'etcd' sabe que esse pod é novo, mas como ele sabe que deve ser a cardinalidade 2 (que vem dos dados armazenados no volume B)?

Em vez de 3 controladores de replicação, por que não um controlador de fragmentação, que
olha para um rótulo como "kubernetes.io/ShardIndex" ao tomar decisões. Se
você quer fragmentação de 3 vias, faz 3 pods com índices 0, 1, 2. Eu sinto que
isso foi derrubado antes, mas não consigo reconstruir o problema que causou em
minha cabeça.

Parece errado colocar esse fardo sobre os usuários se este for um
cenário comum.

Você acha que importa se o IP nominal para um determinado pod muda devido a
mudanças não relacionadas no conjunto? Por exemplo:

no tempo 0, os pods (A, B, C) constituem um serviço cardinal, com IP's
10.0.0. {1-3} respectivamente

no tempo 1, o nó que hospeda o pod B morre

no tempo 2, o controlador de replicação que conduz B cria um novo pod D

no tempo 3, o serviço cardinal muda para (A, C, D) com o IP 10.0.0. {1-3}
respectivamente

NB: o "IP estável" do pod C mudou de 10.0.0.3 para 10.0.0.2 quando o conjunto
a adesão mudou. Espero que isso vá prejudicar a execução
conexões.

Para contornar isso, precisaríamos ter os valores ordinais especificados
fora do serviço, ou algo mais inteligente. Talvez esteja tudo bem, mas
parece frágil e fácil de errar se as pessoas tiverem que lidar com isso.

Em quinta-feira, 2 de outubro de 2014 às 10:17, Clayton Coleman [email protected]
escreveu:

As atribuições teriam que ser realizadas nos pods por meio de alguns
mecanismo de parametrização do ambiente (quase certamente).

Para o exemplo do etcd, eu criaria:

• cardinalidade do controlador de replicação 1: 1 pod, apontando para estável
  volume de armazenamento A
• cardinalidade do controlador de replicação 2: 1 pod, apontando para estável
  volume de armazenamento B
• cardinalidade do controlador de replicação 3: 1 pod, apontando para estável
  volume de armazenamento C
• serviço cardinal 'etcd' apontando para os pods

Se o pod 2 morrer, o controlador de replicação 2 criará uma nova cópia dele e
o reconecta ao volume B. O serviço Cardinal 'etcd' sabe que esse pod é
novo, mas como ele sabe que deveria ser a cardinalidade 2 (que vem de
dados armazenados no volume B)?

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

Acho que um controlador de fragmentação faz sentido e é provavelmente mais útil no contexto de um serviço cardinal.

Eu realmente acho que as mudanças de IP com base na associação são assustadoras e posso pensar em um monte de casos extremos degenerados. No entanto, se a cardinalidade for armazenada com os frutos, a decisão é menos difícil.

Em primeiro lugar, não pretendia que fosse sobre fragmentação - é o # 1064. Vamos mover as discussões sobre fragmentação para lá. Vimos muitos casos de tentativa de uso de um mecanismo análogo para fragmentação e concluímos que não é a melhor maneira de implementar a fragmentação.

Em segundo lugar, minha intenção é que não seja necessário executar N controladores de replicação. Deve ser possível usar apenas um, embora o número necessário dependa dos detalhes de implantação (canários, várias faixas de lançamento, atualizações contínuas, etc.).

Terceiro, concordo que precisamos considerar como isso interagiria com a proposta de dados duráveis ​​(# 1515) - @erictune .

Quatro, concordo que provavelmente precisamos refletir a identidade no pod. De acordo com o nº 386, o ideal é que um mecanismo padrão seja usado para tornar as atribuições de nomes de IP e DNS visíveis para o pod. Como o IP e os aliases de host normalmente apareceriam no Linux?

Quinto, sugeri que garantíssemos a estabilidade das atribuições gravando as atribuições nos pods por meio de rótulos ou anotações.

Sexto, o problema com um "controlador de fragmentação" substituindo o controlador de replicação é que desejo desacoplar a atribuição de função do gerenciamento de imagem / ambiente. Vejo que o controlador de replicação fornece o último (consulte https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

No caso de dados duráveis, conforme # 1515:

1. Para cápsulas duráveis, esta proposta simplesmente funcionaria. A atribuição seria estável para o pod durável.
2. Para objetos de dados separados, o serviço cardinal também precisaria gerenciar a atribuição de funções para os objetos de dados e adiar a atribuição de funções aos pods até depois de serem correspondidos aos dados. Acho que isso seria direto.

/ cc @erictune

Acho que você estava tentando tornar a conversa mais fácil, mas não tenho certeza se funcionou.

Re: sharding - "um conjunto de réplicas com identidade distinta" não é basicamente sharding?

Re: 1 controlador de replicação - não temos índices de atribuição de controlador de replicação hoje. Acho que não queremos isso, queremos?

Re: dizer ao pod sua própria identidade - o serviço é uma camada limpa sobre o pod. Seria complicado contar a um serviço sobre um pod iminente para que ele pudesse atribuir um IP antes que ele existisse. Acho que o ID precisa fazer parte do pod, por exemplo, um rótulo ShardIndex ou algo assim. Podemos refletir isso no pod (de alguma forma) e o serviço pode usar isso para atribuir o IP. Se deixarmos o serviço Cardinal fazer isso sozinho, o pod já terá sido iniciado no momento em que for atribuído. Poderíamos ter metadados por pod como fazemos com VMs no GCE, mas essa é uma proposta maior.

Não, fornecer identidades estáveis ​​e distintas não é necessário nem suficiente para fragmentação. Veja # 1064 para detalhes, que acabei de adicionar lá.

Não, não queremos que o controlador de replicação atribua índices. Propus intencionalmente que os serviços do Cardinal o fizessem.

Sim, espero que os pods existam (e possivelmente tenham sido iniciados) antes de receberem funções (índices). Isso foi deliberado. Também deve ser possível revogar uma atribuição.

Possível abordagem de identidade: Crie um alias de IP não persistente no contêiner e forneça pesquisa reversa de DNS na implementação de DNS.

No entanto, não acho que inserir a identidade nos contêineres de pod seja essencial para muitos casos de uso. Se o aplicativo estiver usando autorregistro, provavelmente nem precisará desse mecanismo.

Se o gerente de serviço estiver disposto a manter algum estado à parte do que ele
atualmente, podemos apenas lembrar os mapeamentos que foram feitos anteriormente
e tente respeitá-los.

Na quinta-feira, 2 de outubro de 2014 às 20:59, bgrant0607 [email protected] escreveu:

Possível abordagem de identidade: Crie um alias de IP não persistente no
contêiner e fornecer pesquisa reversa de DNS na implementação de DNS.

No entanto, não acho que colocar a identidade nos contêineres de cápsulas seja
essencial para muitos casos de uso. Se o aplicativo estiver usando
auto-registro, provavelmente nem precisa desse mecanismo.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Ré. lembrando dos mapeamentos, eu concordo - consulte https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Não sei como isso é relevante para o comentário ao qual você respondeu, no entanto.

GitHub e e-mail não combinam. Desculpe

Na quinta-feira, 2 de outubro de 2014 às 21h39, bgrant0607 [email protected] escreveu:

Ré. lembrando dos mapeamentos, eu concordo - ver # 260 (comentário)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Não sei como isso é relevante para o comentário ao qual você respondeu, no entanto.

Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim sugeriu "nominal", o que concordo é um ajuste melhor.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

Eu gosto de nomes nominais também. Odiará explicá-lo aos usuários, mas muitas vezes vai ser usado para coisas criadas por configuração (ou seja, um conjunto de réplicas mongodb nominal será um controlador de replicação, um serviço nominal, volumes, então já é um tanto complexo).

----- Mensagem original -----

Tim sugeriu "nominal", o que concordo é um ajuste melhor.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Dois problemas que vejo:

1. A atribuição de função envolve definir pelo menos variáveis ​​de ambiente ou configurações de volume por pod (ou seja, o primeiro pod precisa obter o volume a e, se excluído, sua substituição precisa desse mesmo volume)
2. Se os pods para um serviço nominal vêm de um único controlador repl, o modelo deve ser modificado após a criação, mas antes que o pod seja vinculado.

Isso parece implicar que a atribuição de função é um controlador que fica entre o apiserver e o planejador como uma etapa do fluxo de trabalho. Também implica alguma forma de transformação ou substituição do modelo, de forma que o modelo sem a atribuição de função não necessariamente faça sentido.

O controlador de shard parece uma variante desse problema, apenas para atribuição de função mais complicada.

Exemplo de execução do zookeeper com um serviço por instância: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Então, eu sei que este é um tópico antigo, mas atinge um tópico que me é caro ;-)

Contanto que o sistema possa avançar + reverter registros de "serviços nominais" não-natados para skydns e usar nomes como a injeção de ENV nos pods que usam esse serviço, há outras limitações?

Pode parecer um pouco estranho no caso de ZK, onde cada elemento do quorum usaria os outros elementos, por exemplo:
zk1 usa: zk2, zk3
zk2 usa: zk1, zk3
zk3 usa: zk1, zk2

mas em teoria deve funcionar certo? Desde que possamos adicionar os registros reversos para os serviços nominais.

@ bgrant0607 estou perdendo alguma coisa?

Fica um pouco mais estranho quando outros aplicativos desejam usar o serviço geral que ele oferece. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc O que você propõe funcionaria se zk1, zk2 e zk3 fossem serviços, pelo menos uma vez que serviços multiportas são suportados.

Sim, há um feio aqui, no entanto.

Um pod em execução não sabe quais serviços o "frontam". Por exemplo, dado um serviço
de uma instância de back-end, o VIP usado para acessar o serviço não é conhecido por
o back-end (a menos que busque essa informação conhecendo o serviço
nome). Em um serviço nominal (N), você teria N back-ends e N VIPs (e
presumivelmente N nomes DNS ou um nome de endereço N), mas os back-ends ainda seriam
não conhece seus próprios VIPs. Eles podem observar o pool de nomes DNS, mas
não sei (sem sondar) qual é o eu. Isso tornaria o seu ZK
caso difícil de usar os VIPs (também os VIPs são procurados de forma observável agora).

Alternativas:

1) configurar 1 serviço (N) e fazer com que cada instância investigue todos os VIPs para si mesmo

2) configurar instâncias de serviço N (1) e usar rótulos e sinalizadores de cmdline para
atribuir índices manualmente, fazer com que cada backend ZK conheça (a priori) o nome DNS
um do outro backend ZK

3) Faça DNS para seletores de rótulo, atribua um nome DNS ao conjunto de réplicas ZK,
espero que os clientes usem DNS corretamente

4) Execute pontes kube2zk ao lado de cada ZK que sincroniza endpoints kubernetes ->
ZK config

5) Projetar uma maneira alternativa de atribuir VIPs ou índices que sejam mais
replcation-controller-centric do que service centric. Brendan e eu
debatemos algumas ideias aqui há algum tempo, mas não tive tempo de segui-las
em cima disso.

Quanto ao DNS reverso - não tenho certeza se vejo o papel dele? Eu não sou contra
apoiá-lo (ou seja, peça a @bketelsen para apoiá-lo :) mas eu não acho
aplica-se aqui. O tráfego nunca vem "de" um IP de serviço.

Tim

No sábado, 7 de março de 2015 às 20:56, Brian Grant [email protected]
escreveu:

@timothysc https://github.com/timothysc O que você propõe funcionaria se
zk1, zk2 e zk3 eram serviços, pelo menos quando os serviços de múltiplas portas são
suportado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) soa como esta proposta.

Eu sou um grande fã de 5 - os pods sabendo sua função são a primeira etapa, os pods tendo uma identificação DNS exclusiva ou usando endpoints para obter ip de outros e reagir a isso são dois. Ser capaz de pesquisar o ip do pod em endpoints por um id de função estável seria o terceiro.

Em 8 de março de 2015, às 11h06, Tim Hockin [email protected] escreveu:

Sim, há um feio aqui, no entanto.

Um pod em execução não sabe quais serviços o "frontam". Por exemplo, dado um serviço
de uma instância de back-end, o VIP usado para acessar o serviço não é conhecido por
o back-end (a menos que busque essa informação conhecendo o serviço
nome). Em um serviço nominal (N), você teria N back-ends e N VIPs (e
presumivelmente N nomes DNS ou um nome de endereço N), mas os back-ends ainda seriam
não conhece seus próprios VIPs. Eles podem observar o pool de nomes DNS, mas
não sei (sem sondar) qual é o eu. Isso tornaria o seu ZK
caso difícil de usar os VIPs (também os VIPs são procurados de forma observável agora).

Alternativas:

1) configurar 1 serviço (N) e fazer com que cada instância investigue todos os VIPs para si mesmo

2) configurar instâncias de serviço N (1) e usar rótulos e sinalizadores de cmdline para
atribuir índices manualmente, fazer com que cada backend ZK conheça (a priori) o nome DNS
um do outro backend ZK

3) Faça DNS para seletores de rótulo, atribua um nome DNS ao conjunto de réplicas ZK,
espero que os clientes usem DNS corretamente

4) Execute pontes kube2zk ao lado de cada ZK que sincroniza endpoints kubernetes ->
ZK config

5) Projetar uma maneira alternativa de atribuir VIPs ou índices que sejam mais
replcation-controller-centric do que service centric. Brendan e eu
debatemos algumas ideias aqui há algum tempo, mas não tive tempo de segui-las
em cima disso.

Quanto ao DNS reverso - não tenho certeza se vejo o papel dele? Eu não sou contra
apoiá-lo (ou seja, peça a @bketelsen para apoiá-lo :) mas eu não acho
aplica-se aqui. O tráfego nunca vem "de" um IP de serviço.

Tim

No sábado, 7 de março de 2015 às 20:56, Brian Grant [email protected]
escreveu:

@timothysc https://github.com/timothysc O que você propõe funcionaria se
zk1, zk2 e zk3 eram serviços, pelo menos quando os serviços de múltiplas portas são
suportado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Vou precisar de algum tempo para redigir um pouco mais essa ideia, então.

No domingo, 8 de março de 2015 às 10:25, Clayton Coleman [email protected]
escreveu:

Eu sou um grande fã de 5 - os pods sabendo sua função é o primeiro passo, os pods
ter um DNS único com a identificação ou usando endpoints para obter outros ip e
reagir a ele são dois. Ser capaz de pesquisar o ip do pod em endpoints por um
o id de papel estável seria o terceiro.

Em 8 de março de 2015, às 11h06, Tim Hockin [email protected]
escreveu:

Sim, há um feio aqui, no entanto.

Um pod em execução não sabe quais serviços o "frontam". Por exemplo, dado um
serviço
de uma instância de back-end, o VIP usado para acessar o serviço não é conhecido
por
o back-end (a menos que busque essa informação conhecendo o serviço
nome). Em um serviço nominal (N), você teria N back-ends e N VIPs
(e
presumivelmente N nomes DNS ou um nome de endereço N), mas os back-ends seriam
ainda
não conhece seus próprios VIPs. Eles podem observar o pool de nomes DNS, mas
não sei (sem sondar) qual é o eu. Isso tornaria o seu ZK
caso difícil de usar os VIPs (também os VIPs são procurados de forma observável agora).

Alternativas:

1) configurar 1 serviço (N) e fazer com que cada instância investigue todos os VIPs para si mesmo

2) configurar instâncias de serviço N (1) e usar rótulos e sinalizadores de cmdline para
atribuir índices manualmente, fazer com que cada backend ZK conheça (a priori) o DNS
nome
um do outro backend ZK

3) Faça DNS para seletores de rótulo, atribua um nome DNS ao conjunto de réplicas ZK,
espero que os clientes usem DNS corretamente

4) Execute pontes kube2zk ao lado de cada ZK que sincroniza endpoints de kubernetes
->
ZK config

5) Projetar uma maneira alternativa de atribuir VIPs ou índices que sejam mais
replcation-controller-centric do que service centric. Brendan e eu
debatemos algumas ideias aqui há algum tempo, mas não tive tempo para
Segue
em cima disso.

Quanto ao DNS reverso - não tenho certeza se vejo o papel dele? Eu não sou contra
apoiá-lo (ou seja, peça a @bketelsen para apoiá-lo :) mas eu não acho
aplica-se aqui. O tráfego nunca vem "de" um IP de serviço.

Tim

No sábado, 7 de março de 2015 às 20:56, Brian Grant [email protected]
escreveu:

@timothysc https://github.com/timothysc O que você propõe funcionaria
E se
zk1, zk2 e zk3 eram serviços, pelo menos quando os serviços de múltiplas portas são
suportado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: DNS reverso, vamos apenas acenar e considerá-lo um requisito.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

RC que aplicou um rótulo exclusivo (membros = #) a cada pod que criou e tentou criar uma sequência de até N réplicas e, em seguida, um serviço sem cabeça que criou um nome A e CNAME para cada valor do rótulo "membro" (# .service.namespace.local), em que a raiz atendia a todos os service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local parece local.

_Podemos_ usar IPs de pod estritos para esses rótulos DNS individuais. Criar IPs falsos para cada um fica caro e o contêiner não conseguirá enviar seu próprio IP para alguém.

----- Mensagem original -----

@thockin re: DNS reverso, vamos apenas acenar e considerá-lo um
requerimento.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: DNS reverso - o que é DNSing reverso? O IP-fonte de
conexões? Nada disso funciona no Kube. Conexões por meio de serviços são
proxy, então source-ip não funciona em primeiro lugar (pode ser corrigido).

Eu não sei ZK - você pode explicar o que eles estão tentando fazer ao contrário
DNS? Parece uma suposição muito frágil.

Na segunda-feira, 9 de março de 2015 às 9h05, Timothy St. Clair [email protected]
escreveu:

@thockin https://github.com/thockin re: DNS reverso, vamos apenas acenar
nossas mãos e considerá-lo um requisito.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Acho que minha experiência (e talvez a de Tim) é que a maioria dos softwares em cluster hoje espera o seguinte:

• cada nó tem uma identidade estável
• essa identidade é um nome DNS
• o IP da identidade subjacente não precisa ser estável
• o nó espera se identificar para outros nós, seja por sua identidade estável (DNS) ou por seu IP público
• alguns dos softwares em cluster esperam que o IP do nó em que um cliente o alcance corresponda a um IP que ele possa anunciar a outros no cluster e que esse IP seja alcançável.

----- Mensagem original -----

@timothysc re: DNS reverso - o que é DNSing reverso? O IP-fonte de
conexões? Nada disso funciona no Kube. Conexões por meio de serviços são
proxy, então source-ip não funciona em primeiro lugar (pode ser corrigido).

Eu não sei ZK - você pode explicar o que eles estão tentando fazer ao contrário
DNS? Parece uma suposição muito frágil.

Na segunda-feira, 9 de março de 2015 às 9h05, Timothy St. Clair [email protected]
escreveu:

@thockin https://github.com/thockin re: DNS reverso, vamos apenas acenar
nossas mãos e considerá-lo um requisito.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

Na segunda-feira, 9 de março de 2015 às 12h49, Clayton Coleman
notificaçõ[email protected] escreveu:

RC que aplicou um rótulo exclusivo (membros = #) a cada pod que criou e tenta criar uma sequência até
N réplicas e, em seguida, um serviço sem cabeçalho que criou um nome A e CNAME para cada valor de "membro"
rótulo (# .service.namespace.local), em que a raiz servia a todos esses service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local parece local.

A ideia de que Brendan e eu estávamos pulando era basicamente uma piscina
de tokens, talvez parte do RC, talvez não, que cada elemento de um RC
seria atribuído. Dado esse token, outras coisas podem ser atribuídas

• VIPs, PDs, índices genéricos, etc. O que é bom é que quando um pod
  morre, o token é retornado ao pool e, quando esse pod é substituído
  esse token é reutilizado.

O problema surge em descobrir como transformar "token arbitrário" em
algo significativo.

_Podemos_ usar IPs de pod estritos para esses rótulos DNS individuais. Criar IPs falsos para cada um fica caro e o contêiner não conseguirá enviar seu próprio IP para alguém.

Não tentei, mas aposto que poderíamos fazer os serviços nominais fazerem SNAT completo
e DNAT, uma vez que são 1: 1. Esta seria uma maneira de ficar estável
por pod IPs sem IPs migráveis.

----- Mensagem original -----

@thockin re: DNS reverso, vamos apenas acenar e considerá-lo um
requerimento.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Longe de mim nadar contra a corrente - se aplicativos suficientes realmente esperam que o DNS
funcionar desta forma, podemos fazer funcionar desta forma.

Esboço:

A criação de um controlador de replicação R cria um nome DNS "$ R.rc" que é o
pool de IPs de pod que estão "sob" esse RC. Cada pod P recebe um nome DNS
"$ P. $ R.rc". Mas o que é P? Podem ser índices simples, mas isso tem
nos mordeu com força internamente. Podem ser strings aleatórias como GenerateName,
mas eles têm que sobreviver à morte / reinicialização do pod (e talvez os nomes de host do pod devam
Combine?).

Na terça-feira, 10 de março de 2015 às 7h59, Clayton Coleman [email protected]
escreveu:

Acho que minha experiência (e talvez a de Tim) é que a maioria dos agrupamentos
o software hoje espera o seguinte:

• cada nó tem uma identidade estável
• essa identidade é um nome DNS
• o IP da identidade subjacente não precisa ser estável
• o nó espera se identificar para outros nós, seja por seu
  identidade (DNS) ou seu IP público
• algum software em cluster espera o IP do nó de um cliente
  alcança-o para corresponder a um IP, ele pode anunciar-se a outros no
  cluster e para que esse IP seja alcançável.

----- Mensagem original -----

@timothysc re: DNS reverso - o que é DNSing reverso? O IP-fonte de
conexões? Nada disso funciona no Kube. Conexões por meio de serviços são
proxy, então source-ip não funciona em primeiro lugar (pode ser corrigido).

Eu não sei ZK - você pode explicar o que eles estão tentando fazer ao contrário
DNS? Parece uma suposição muito frágil.

Na segunda-feira, 9 de março de 2015 às 9h05, Timothy St. Clair <
notificaçõ[email protected]>
escreveu:

@thockin https://github.com/thockin re: DNS reverso, vamos apenas acenar
nossas mãos e considerá-lo um requisito.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

Eu meio que gosto de DNS sendo anexado a serviços nominais em vez de RC.

Qual foi o ponto de dor com índices simples internamente? P> 5000?

----- Mensagem original -----

Longe de mim nadar contra a corrente - se aplicativos suficientes realmente esperam que o DNS
funcionar desta forma, podemos fazer funcionar desta forma.

Esboço:

A criação de um controlador de replicação R cria um nome DNS "$ R.rc" que é o
pool de IPs de pod que estão "sob" esse RC. Cada pod P recebe um nome DNS
"$ P. $ R.rc". Mas o que é P? Podem ser índices simples, mas isso tem
nos mordeu com força internamente. Podem ser strings aleatórias como GenerateName,
mas eles têm que sobreviver à morte / reinicialização do pod (e talvez os nomes de host do pod devam
Combine?).

Na terça-feira, 10 de março de 2015 às 7h59, Clayton Coleman [email protected]
escreveu:

Acho que minha experiência (e talvez a de Tim) é que a maioria dos agrupamentos
o software hoje espera o seguinte:

• cada nó tem uma identidade estável
• essa identidade é um nome DNS
• o IP da identidade subjacente não precisa ser estável
• o nó espera se identificar para outros nós, seja por seu
  identidade (DNS) ou seu IP público
• algum software em cluster espera o IP do nó de um cliente
  alcança-o para corresponder a um IP, ele pode anunciar-se a outros no
  cluster e para que esse IP seja alcançável.

----- Mensagem original -----

@timothysc re: DNS reverso - o que é DNSing reverso? O IP-fonte de
conexões? Nada disso funciona no Kube. Conexões por meio de serviços são
proxy, então source-ip não funciona em primeiro lugar (pode ser corrigido).

Eu não sei ZK - você pode explicar o que eles estão tentando fazer ao contrário
DNS? Parece uma suposição muito frágil.

Na segunda-feira, 9 de março de 2015 às 9h05, Timothy St. Clair <
notificaçõ[email protected]>
escreveu:

@thockin https://github.com/thockin re: DNS reverso, vamos apenas acenar
nossas mãos e considerá-lo um requisito.

O ZK irá quebrar sem ele, assim como muitos outros sistemas distribuídos.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 para VIPs especiais 1: 1. Acho que vai ser um caso comum.

Ainda estou preocupado em alterar os mapeamentos DNS dinamicamente. Eu prefiro uma abordagem que não exija isso.

Algo para ter em mente ao avaliar alternativas é que estou 100% certo de que, no final, precisaremos de 2 pods com a mesma função para coexistir ao mesmo tempo, o antigo e o novo. Portanto, o papel não pode ser vinculado ao nome do objeto nem a qualquer outra coisa que deve ser única e deve ser gravada em pedra no momento da criação do pod.

Se amarrarmos o mecanismo de atribuição de função ao controlador de replicação, isso praticamente eliminará a implementação de atualizações, canários etc. Eu gostaria de evitar isso, se possível.

@smarterclayton Índices simples não são problemáticos devido à escala. É devido ao modelo. Veja meus comentários de alguns minutos atrás. Índices simples são o caminho a percorrer se puderem ser atribuídos dinamicamente, independentemente do pod e da identidade RC.

Dado que um dos problemas são as suposições orientadas ao sistema, há algo que o Linux poderia fazer por nós aqui? Por exemplo, poderíamos criar um alias de IP ou algo assim no contêiner para o serviço VIP?

Ei pessoal,

Eu estou fora a semana toda. Esta é uma conversa muito divertida, mas requer
mais tempo do que tenho à mão. Eu ficaria feliz em sentar e discutir na vida real
tempo na próxima semana.

Na terça-feira, 10 de março de 2015 às 15:56, Brian Grant [email protected]
escreveu:

Dado que um dos problemas são as suposições orientadas para o sistema, há
algo que o Linux poderia fazer por nós aqui? Por exemplo, poderíamos criar um IP
alias ou algo assim no container para o serviço VIP?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Eu estarei fora do bolso nos próximos dois dias - na semana que vem, sim.

Em 10 de março de 2015, às 23h33, Tim Hockin [email protected] escreveu:

Ei pessoal,

Eu estou fora a semana toda. Esta é uma conversa muito divertida, mas requer
mais tempo do que tenho à mão. Eu ficaria feliz em sentar e discutir na vida real
tempo na próxima semana.

Na terça-feira, 10 de março de 2015 às 15:56, Brian Grant [email protected]
escreveu:

Dado que um dos problemas são as suposições orientadas para o sistema, há
algo que o Linux poderia fazer por nós aqui? Por exemplo, poderíamos criar um IP
alias ou algo assim no container para o serviço VIP?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

+1 para a próxima semana, talvez um hangout.

Tentando novamente devido ao surgimento de tópicos relacionados (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, # 6393).

1. Como atribuímos identidades de rede (nomes DNS e / ou endereços IP) a pods individuais, que podem ser singletons ou parte de um conjunto nominal?
2. Como transmitimos a identidade aos contêineres de um pod?

Devemos agendar um hangout ou usar um hangout semanal da comunidade?

Além disso, https://github.com/openshift/mongodb/pull/14, que estamos começando a fazer o protótipo de um padrão genérico para a inicialização do conjunto de membros (algo que podemos colocar em um contêiner, ou biblioteca, ou ...)

@danmcp @mfojtik

----- Mensagem original -----

Tocando este tópico novamente devido ao surgimento de tópicos relacionados
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. Como atribuímos identidades de rede (nomes DNS e / ou endereços IP) para
   pods individuais, que podem ser singletons ou parte de um conjunto nominal?
2. Como transmitimos a identidade aos contêineres de um pod?

Devemos agendar um hangout ou usar um hangout semanal da comunidade?

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, uma peça desse quebra-cabeça é a eleição geral nº 1542.

Sim, nós discutimos isso. Para a maioria dos clusters, que podem fazer sua própria eleição, a associação é o mais importante (detectar a associação de terminais Kube, aplicar ao cluster), mas sempre há maneiras diferentes de abordar isso. Por exemplo, Cassandra basicamente usa o Kube como a fonte externa da verdade para os membros, então é SEP e isso torna a eleição da liderança mais fácil. Embora eu acredite que dependendo de como os membros ficam, você pode acabar com uma partição se o número de membros falhar.

Para mongo, você deseja entrar em contato com cada um dos membros e fazer com que eles se juntem a um cluster existente ou formem um novo cluster. Se houver vários clusters, você não deseja torná-los piores.

Observe que o problema de comunicação de um IP de serviço para um contêiner é semelhante à comunicação de um IP externo para uma VM: https://cloud.google.com/compute/docs/networking. O GCE traduz os endereços externos de / para os endereços internos, e os endereços externos são comunicados por meio do servidor de metadados: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS é semelhante: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton Eu atualizei o protótipo do mongo PR: https://github.com/openshift/mongodb/pull/17

agora está usando um pod de disparo que inicializa o replicaSet

Ré. amarrando este mecanismo ao controlador de replicação / fragmento:

Tentar nomes DNS para controladores de replicação e / ou nomes de objetos de pod força um modelo de atualização local. Um tipo completamente diferente de atualização contínua "in-loco" precisaria ser implementado, embora de alguma forma suporte vários modelos simultaneamente com um único controlador. Isso também significaria que, para realizar alguns tipos de atualizações (incluindo a mudança para novos hosts), os pods precisariam ser excluídos e recriados com os mesmos nomes, o que aumentaria o tempo de inatividade em comparação com a abordagem em que adicionamos um novo vagem antes de tirar um velho.

A ideia do conjunto de tokens parece ótima. Só acho que precisa ser dissociado dos RCs.

Isso poderia ser acoplado a um controlador de nível superior, se adicionarmos um. Comentará mais sobre # 1743 e / ou # 503.

Isso realmente não deve ser acoplado ao DeploymentController proposto em # 1743. Não funcionaria para o cenário de várias faixas de lançamento independentes, nem no caso em que alguém quisesse controlar seus lançamentos com um mecanismo diferente, como a atualização contínua de troca de nome proposta. Por motivos semelhantes, eu não vincularia os nomes DNS a nomes de objetos pod / RC / DC.

Portanto, estamos de volta a algum tipo de serviço, ou um controlador totalmente separado. Talvez o controlador de endpoints pudesse atribuir índices a endpoints de serviço? O próprio Endpoints é um local confiável o suficiente para registrar esses dados? Se fosse perdido, todos os pods seriam reindexados.

Para facilitar a comunicação de identidade para os contêineres no pod (como via env. Var. Substituição discutida em # 2316), seria útil definir um campo no pod quando a função fosse atribuída / não atribuída, por meio de um sub-recurso. Isso também pode resolver o problema da durabilidade.

Devemos reservar espaço no esquema DNS para instâncias nominais - # 6666.

Eu poderia comprar que poderíamos tentar usar IPs de pod e apenas remapear DNS para instâncias nominais, por https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

Além disso, removi isso do marco 1.0 em fevereiro (embora não roadmap.md), mas a discussão em # 6393 sugere que pode ser adicionado novamente.

Sugerido por @thockin : a pesquisa reversa usando DNS (registros PTR) parece uma maneira razoável de ir de IPs de pod para nomes DNS nominais:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Sim, tornaria "quem sou eu" realmente fácil por meio de ferramentas de nomes padrão.

Em 10 de abril de 2015, às 20:11, Brian Grant [email protected] escreveu:

Sugerido por @thockin : a pesquisa reversa usando DNS (registros PTR) parece uma maneira razoável de ir de IPs de pod para nomes DNS nominais:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

/se inscrever

Não tenho mais certeza se entendi os requisitos aqui.

Existe uma relação N-para-M inerente entre os serviços e pods, pelo
projeto do sistema. Coisas como DNS reverso geralmente esperam obter um
resposta única: dado o IP de um pod, obtenha um nome canônico. Cada documento escrito
sobre o DNS diz "não retornar vários registros reversos". Uma vez que um pod pode ser
em N serviços, essa única resposta não pode estar realmente relacionada ao serviço. Nós
poderia fazer uma pesquisa reversa para um nome canônico e, em seguida, uma pesquisa TXT sobre esse
nome para "em quais serviços você está", mas isso é difícil de manter e é
essencialmente um protocolo personalizado de qualquer maneira.

A razão pela qual pensei em atribuir algo nominal aos RCs é que isso é um
relacionamento mais concreto. Mas não é mesmo. Um pod pode ser criado por
um RC, órfão, adotado por outro RC e destruído por este. Ou
destruído manualmente

Portanto, não tenho certeza do que queremos fazer com isso, exceto limitar o número
de serviços, um pod pode estar "sob", o que parece horrível.

Quais são os requisitos comportamentais? O que estamos tentando alcançar. Nós
pode fornecer semântica de conjunto simples com DNS e serviços sem comando. É aquele
suficiente? Se não, por quê?

Poderíamos ir a extremos e configurar regras de iptables para pods SNAT / DNAT em um
serviço para que todos se vejam nos VIPs. Por exemplo, dado um conjunto de pods
(P1, P2, P3) eles obteriam VIPs (V1, V2, V3). O tráfego de P1 para V2 seria
parecem vir de V1, etc. Os clientes acessariam V {1,2,3}. Mas o que
problema isso resolve, realmente? Ele fornece IPs estáveis, mas isso não é um
problema geral para serviços sem cabeça por toda parte?

Na terça-feira, 21 de abril de 2015 às 14h17, David Oppenheimer < [email protected]

escreveu:

/se inscrever

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

O objetivo era muito concreto. Os sistemas em cluster reais têm membros que possuem uma "identidade" que se espera que seja contínua na presença de falhas de nó. Essa identidade pode ser anexada a um disco permanente ou um "nome", mas o nome que a identifica para outros sistemas não pode ser alterado.

Por exemplo, o zookeeper tem uma identidade por nó. Essa identidade deve permanecer estável na associação do cluster - _pode_ haver dois pods que pensam que são o host1, mas se o host1 desaparecer, o host435 não poderá substituí-lo. Pode haver um disco permanente reutilizado para esse pod que se move de um lugar para outro, mas quando isso acontece, o pod precisa ser capaz de definir essa identidade. Mas precisamos encontrar uma maneira de atribuir esse #.

Suspeito que a maneira como penso sobre os serviços nominais é sempre sobre como habilitar o software existente com uma associação pequena (3/5/7), não o caso de uso totalmente flexível de várias centenas. Talvez devêssemos separar esse caso de uso desta discussão.

Em 22 de abril de 2015, à 1h59, Tim Hockin [email protected] escreveu:

Não tenho mais certeza se entendi os requisitos aqui.

Existe uma relação N-para-M inerente entre os serviços e pods, pelo
projeto do sistema. Coisas como DNS reverso geralmente esperam obter um
resposta única: dado o IP de um pod, obtenha um nome canônico. Cada documento escrito
sobre o DNS diz "não retornar vários registros reversos". Uma vez que um pod pode ser
em N serviços, essa única resposta não pode estar realmente relacionada ao serviço. Nós
poderia fazer uma pesquisa reversa para um nome canônico e, em seguida, uma pesquisa TXT sobre esse
nome para "em quais serviços você está", mas isso é difícil de manter e é
essencialmente um protocolo personalizado de qualquer maneira.

A razão pela qual pensei em atribuir algo nominal aos RCs é que isso é um
relacionamento mais concreto. Mas não é mesmo. Um pod pode ser criado por
um RC, órfão, adotado por outro RC e destruído por este. Ou
destruído manualmente

Portanto, não tenho certeza do que queremos fazer com isso, exceto limitar o número
de serviços, um pod pode estar "sob", o que parece horrível.

Quais são os requisitos comportamentais? O que estamos tentando alcançar. Nós
pode fornecer semântica de conjunto simples com DNS e serviços sem comando. É aquele
suficiente? Se não, por quê?

Poderíamos ir a extremos e configurar regras de iptables para pods SNAT / DNAT em um
serviço para que todos se vejam nos VIPs. Por exemplo, dado um conjunto de pods
(P1, P2, P3) eles obteriam VIPs (V1, V2, V3). O tráfego de P1 para V2 seria
parecem vir de V1, etc. Os clientes acessariam V {1,2,3}. Mas o que
problema isso resolve, realmente? Ele fornece IPs estáveis, mas isso não é um
problema geral para serviços sem cabeça por toda parte?

Na terça-feira, 21 de abril de 2015 às 14h17, David Oppenheimer < [email protected]

escreveu:

/se inscrever

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Algum tipo de controlador pode definir / remover dinamicamente alguns campos nos pods. Simplesmente não pode ser confundido com o pod nem com a identidade RC. Amarrar a identidade da rede a identidades de pod ou RC é totalmente quebrado.

Eu não tentaria fazer a pesquisa reversa de DNS funcionar para serviços comuns ou sem comando, e não acho que seja razoável impor um máximo de um serviço nominal por pod - o que não precisa limitar outros tipos de serviços. .

Há uma série de limitações de DNS que queremos implementar a longo prazo (invalidação de cache, suporte para long polling, etc.). Vários registros PTR são talvez apenas mais um item adicionado a essa lista.

A outra alternativa é que podemos dar um IP de serviço para cada pod do serviço nominal e então resolver os problemas que isso cria.

----- Mensagem original -----

Algum tipo de controlador pode definir / remover dinamicamente alguns campos nos pods. Isto
simplesmente não pode ser confundido com o pod nem com a identidade RC. Amarrando a identidade da rede
para identidades de pod ou RC está totalmente quebrado.

Eu não tentaria fazer a pesquisa reversa de DNS funcionar para usuários comuns ou sem cabeça
serviços, e eu não acho que seja razoável impor um máximo de um valor nominal
serviço por pod - o que não precisa limitar outros tipos de serviços em
tudo.

Há uma série de limitações de DNS que queremos implementar a longo prazo
(invalidação de cache, suporte para long polling, etc.). Vários registros PTR
é talvez apenas mais um item adicionado a essa lista.

A outra alternativa é que podemos dar um IP de serviço para cada pod do
serviço nominal e, em seguida, resolver os problemas que isso cria.

Muitos desses serviços esperam que o IP que eles têm (seu nome) seja resolvido para o IP ao qual se conectam - portanto, se eles se conectam ao X em 172.1.1.1, o X pensa que é 172.1.1.1. Nem tudo é software, mas parte dele. Normalmente é um nome DNS, o que significa que o IP pode mudar por baixo.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

Receio que tudo isso ainda seja um pouco abstrato para mim.

Os sistemas em cluster reais têm membros que têm uma "identidade" que é
deverá ser contínuo na presença de falhas de nó. Essa identidade
pode ser anexado a um disco permanente ou um "nome", mas o nome a
identificar para outros sistemas não pode mudar.

Isso não é um requerimento. É tão vago que não pode ser implementado.

Por exemplo, o zookeeper tem uma identidade por nó. Essa identidade deve permanecer
estável em associação de cluster

O que é uma identidade? Um endereço IP? Uma bandeira de string passada para o software?
e env var? Como um processo zk aprende qual é sua própria identidade?

Algum tipo de controlador pode definir / remover dinamicamente alguns campos nos pods

O que fará com que esses pods sejam reiniciados e ainda não responde ao
questão de quais campos, quais valores e que lógica dizer ao pod?

Eu poderia ver algo como expandir anotações em sinalizadores de linha de comando
(como estamos discutindo com env vars) ou apenas em env vars. Por exemplo
controlador escreve anotações ["zookeeper.com/index"] = 9, nós convertemos
$ .metatdata ["zookeeper.com/index"] em ZK_INDEX env. Mas estou fazendo isso
, eu não vi nenhuma demanda concreta que diga o que exatamente zookeeper (ou
tanto faz) precisa.

Não acho que seja razoável impor no máximo um serviço nominal
por pod

Acho que será difícil implementar tais restrições. O sistema é tão
fracamente acoplado e assíncrono que impor esses limites pode ser pior do que
apenas resolvendo os problemas.

podemos dar um IP de serviço para cada pod do serviço nominal

Foi aqui que começamos, mas ...

Muitos desses serviços esperam que o IP que possuem (seu nome)
resolve para o IP ao qual eles se conectam - portanto, se eles se conectarem ao X em 172.1.1.1,
então X pensa que é 172.1.1.

IPs de serviço não satisfazem isso, a menos que façamos algo mais aprofundado como
Eu mencionei com SNAT / DNAT. E mesmo isso tem deficiências reais.

Não estou tentando ser um pé no saco, é que temos muito pouco
tempo na corrida para 1.0, e não há nada aqui que seja claro o suficiente para
mesmo a prova de conceito, muito menos a implementação adequada.

Estou tentando definir exatamente o que queremos experimentar para que eu possa ver
o que podemos implementar. Dadas as referências repetidas ao DNS, estou segurando
desativar o retrabalho do DNS até saber o que está acontecendo aqui.

Na quarta-feira, 22 de abril de 2015 às 10:12, Clayton Coleman [email protected]
escreveu:

----- Mensagem original -----

Algum tipo de controlador pode ativar / desativar dinamicamente alguns campos
vagens. Isto
simplesmente não pode ser confundido com o pod nem com a identidade RC. Amarrando a rede
identidade
para identidades de pod ou RC está totalmente quebrado.

Eu não tentaria fazer a pesquisa reversa de DNS funcionar para usuários comuns ou sem cabeça
serviços, e não acho que seja razoável impor no máximo um
nominal
serviço por pod - o que não precisa limitar outros tipos de serviços em
tudo.

Há uma série de limitações de DNS que queremos seguir por muito tempo
corre
(invalidação de cache, suporte para long polling, etc.). PTR múltiplo
registros
é talvez apenas mais um item adicionado a essa lista.

A outra alternativa é que podemos dar um IP de serviço para cada pod do
serviço nominal e, em seguida, resolver os problemas que isso cria.

Muitos desses serviços esperam que o IP que eles têm (seu nome) resolva
ao IP ao qual eles se conectam - então, se eles se conectarem a X em 172.1.1.1, então X
pensa que é 172.1.1.1. Nem tudo é software, mas parte dele. Normalmente é
um nome DNS, porém, o que significa que o IP pode mudar por baixo.

---

Responda a este e-mail diretamente ou visualize-o no GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

A maioria dos exemplos de múltiplas portas são sistemas em cluster. Por exemplo:
ZK : nome de host ou endereço IP resolvível em um arquivo de configuração, mais um "id" (ou seja, um índice: 1, 2, 3, ...) em um arquivo

Devemos também examinar alguns bancos de dados.

O que quer que façamos não funcionará para tudo. Só precisamos encontrar o ponto ideal.

----- Mensagem original -----

Receio que tudo isso ainda seja um pouco abstrato para mim.

Os sistemas em cluster reais têm membros que têm uma "identidade" que é
deverá ser contínuo na presença de falhas de nó. Essa identidade
pode ser anexado a um disco permanente ou um "nome", mas o nome a
identificar para outros sistemas não pode mudar.

Isso não é um requerimento. É tão vago que não pode ser implementado.

Por exemplo, o zookeeper tem uma identidade por nó. Essa identidade deve permanecer
estável em associação de cluster

O que é uma identidade? Um endereço IP? Uma bandeira de string passada para o software?
e env var? Como um processo zk aprende qual é sua própria identidade?

Algum tipo de controlador pode definir / remover dinamicamente alguns campos nos pods

O que fará com que esses pods sejam reiniciados e ainda não responde ao
questão de quais campos, quais valores e que lógica dizer ao pod?

Eu poderia ver algo como expandir anotações em sinalizadores de linha de comando
(como estamos discutindo com env vars) ou apenas em env vars. Por exemplo
controlador escreve anotações ["zookeeper.com/index"] = 9, nós convertemos
$ .metatdata ["zookeeper.com/index"] em ZK_INDEX env. Mas estou fazendo isso
, eu não vi nenhuma demanda concreta que diga o que exatamente zookeeper (ou
tanto faz) precisa.

Não acho que seja razoável impor no máximo um serviço nominal
por pod

Acho que será difícil implementar tais restrições. O sistema é tão
fracamente acoplado e assíncrono que impor esses limites pode ser pior do que
apenas resolvendo os problemas.

podemos dar um IP de serviço para cada pod do serviço nominal

Foi aqui que começamos, mas ...

Muitos desses serviços esperam que o IP que possuem (seu nome)
resolve para o IP ao qual eles se conectam - portanto, se eles se conectarem ao X em 172.1.1.1,
então X pensa que é 172.1.1.

IPs de serviço não satisfazem isso, a menos que façamos algo mais aprofundado como
Eu mencionei com SNAT / DNAT. E mesmo isso tem deficiências reais.

Não estou tentando ser um pé no saco, é que temos muito pouco
tempo na corrida para 1.0, e não há nada aqui que seja claro o suficiente para
mesmo a prova de conceito, muito menos a implementação adequada.

Estou tentando definir exatamente o que queremos experimentar para que eu possa ver
o que podemos implementar. Dadas as referências repetidas ao DNS, estou segurando
desativar o retrabalho do DNS até saber o que está acontecendo aqui.

Acho que é sensato, devemos dedicar tempo especificamente para resolver um conjunto de exemplos conhecidos. Temos 3 do nosso lado que podemos aproveitar para exemplos concretos (conjunto de réplicas do MongoDB, Zookeeper, Mysql Master / Slave), bem como os exemplos existentes no kube / examples. Talvez uma sessão de trabalho para verificar os itens, definir limites para problemas insolúveis, identificar o que resta.

Sugira alterar o nome desse recurso, pois ele também pode ser usado para trabalhos em lote para atribuir um número de ID de shard.

Os trabalhos em lote têm requisitos um pouco diferentes, então eu gostaria de mantê-los separados.

Exemplo de zookeeper: https://github.com/openshift/origin/pull/1965

Exemplo de ish de serviço nominal precisa https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Estou meio confuso por que a direção ainda não está clara aqui - principalmente para os Googlers. O Google tem executado serviços com monitoração de estado em Borg por muitos anos e está bastante claro o que é necessário para este tipo de carga de trabalho:

• Um identificador estável para qual do conjunto de "fragmentos" (réplicas não idênticas) o pod atual representa (em borg, esse é o "número da tarefa" - um inteiro simples). Esse identificador deve permanecer constante durante as reprogramações / reinicializações do pod.
• Uma maneira de enumerar e contatar todos os fragmentos "pares", provavelmente usando seus identificadores estáveis ​​de alguma forma (em borg, este é um prefixo rechonchudo junto com o número da tarefa)

.. e terminamos.

Observação: se a exclusão de recursos for crítica para cada fragmento, os aplicativos precisarão fazer seu próprio bloqueio distribuído, pois sempre há a possibilidade de que os tempos de vida do pod possam se sobrepor durante falhas / reinicializações (talvez usando um bloqueio etcd com base no identificador de fragmento). Uma extensão de recurso exótico em potencial é permitir mais de uma réplica idêntica dentro de cada shard, para redundância / carga.

Isso pode ser falsificado agora, criando um serviço / porta exclusivo para cada fragmento e executando um controlador de replicação com réplicas: 1, mas é um pouco desajeitado gerenciar um grande número de fragmentos "manualmente" como este.

Uma maneira natural de implementar isso em kubernetes pode ser:

• Os pods obtêm variáveis ​​de ambiente adicionais, fornecendo seu próprio índice de fragmentos (inteiro) e o número total de fragmentos (ou talvez se comuniquem por meio da API descendente?).
• Os ReplicationControllers obtêm uma contagem de "fragmentos" (padrão: 1) e "réplicas" é reinterpretada para significar "réplicas dentro de cada fragmento" (padrão: 1). Ao reduzir o conjunto de réplicas, eles devem matar a partir do final (para manter os índices de shard contíguos). Observe que alterar "shards" exigirá uma reinicialização contínua dos pods controlados para atualizar seu env var "total shards" (bom, você não quer que isso aconteça instantaneamente).
• Os serviços obtêm uma contagem de "fragmentos" semelhante que mapeia um intervalo contíguo de portas para o seletor regular mais um seletor de "índice de fragmentos" implícito.
• Os pods podem encontrar outros fragmentos usando SERVICE_PORT (ou algum novo env var?) + Deslocamento de índice de fragmentos.

Observe que o acima é degradado normalmente para o comportamento atual quando shards = 1.

Eu geralmente concordo com isso (e como você disse, serviu ao teste do tempo em Borg), embora eu não aconselhe a "extensão de recurso exótico" de múltiplas réplicas por fragmento (embora provavelmente precisemos de algo assim no capas para migração).

Como mencionei anteriormente, isso está intimamente relacionado ao que precisamos fazer para oferecer suporte a trabalhos em lote com atribuição de trabalho estática (o que eu estava chamando de "tipo 1" aqui: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142)

Os outros recursos que precisamos alinhar se mudarmos o RC (ou adicionarmos algo novo) são como a implantação se encaixa, especificamente:

Como faço uma atualização contínua para:

1. Um RC regular
2. Um PerNodeController
3. Um RC fragmentado
4. Um trabalho em lote?

Podemos querer manter a implementação da implantação até que tenhamos um espantalho para cada um deles, porque acredito que uma implantação que só funciona com um RC simples tem alguns problemas.

----- Mensagem original -----

Eu geralmente concordo com isso (e como você diz, serviu ao teste do tempo
em Borg), embora eu desaconselhe o uso do "recurso exótico
extensão "de múltiplas réplicas por fragmento (embora provavelmente precisemos de algo
como aquele sob as cobertas para a migração).

Como mencionei anteriormente, isso está intimamente relacionado ao que precisamos fazer para
suporta trabalhos em lote com atribuição de trabalho estático (o que eu estava chamando de "tipo 1"
aqui:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

Optamos por não priorizar isso (e geramos automaticamente as declarações de volume persistente) para 1.0 porque existem várias soluções alternativas, como a criação de um serviço, RC e declaração de volume persistente por instância.

Embora índices de tarefas densamente atribuídos estaticamente em Borg sejam amplamente usados, aprendemos que eles têm uma série de deficiências e passamos algum tempo nos últimos anos desenvolvendo alternativas. Muitos dos problemas decorrem do fato de que os índices estão associados ao ciclo de vida e à identidade das próprias tarefas. Isso torna difícil implementar uma série de estratégias de implantação, migração, gerenciamento de tarefas dinâmicas e muitos outros cenários. Outra complexidade decorre da geração estática de configuração por índice para cada pré-implantação de tarefa - isso é equivalente a gerar um RC por valor de índice. Isso seria fácil para alguém fazer se realmente quisesse. As etiquetas ainda podem ser usadas para destruir todo o conjunto.

Controlador por nó / daemon: Bom ponto. Índices densamente atribuídos são um modelo ruim para esse caso. O que você faz quando um nó desaparece permanentemente, por exemplo? Os índices tornam-se esparsos. Eu recomendo que não apoiemos isso.

Trabalhos em lote: conforme discutido em # 1624, gostaríamos de atribuir índices com base em conclusões, não em pods em execução no momento.

Conforme discutido acima, a atribuição de índice precisa levar em conta o armazenamento associado, como declarações de volume persistentes - a identidade origina-se da identidade da rede (nome DNS e / ou endereço IP) e do armazenamento.

A atribuição não pode ser conduzida por um único controlador de replicação. Isso simplesmente não funciona. Os controladores de replicação não são entidades duráveis ​​e esperamos que haja vários RCs por serviço, para canários, atualizações contínuas, várias faixas de lançamento, vários clusters, etc. Mesmo o objeto de implantação proposto (# 1743) não tem o escopo correto .

Existem 3 alternativas para atribuição:

1. Associe a atribuição a um tipo especial de serviço. O serviço tem exatamente o escopo correto. (Eventualmente, também precisaremos de serviços regionais.) Isso seria uma espécie de híbrido entre serviços regulares e serviços sem cabeça. É o que imaginei quando propus originalmente este mecanismo. A atribuição seria registrada no Endpoints. Endpoints e / ou DNS sem cabeça seriam as maneiras óbvias de enumerar todos os pares.
2. Crie um novo tipo de objeto semelhante a Serviço, mas apenas para serviços nominais. Provavelmente precisaríamos de um novo objeto para registrar a tarefa também. Isso expandiria nossa superfície de API desnecessariamente, IMO.
3. "Puxe" em vez de "empurre". Os pods são programados para hosts sem um controlador explícito, mesmo com restrições de nó (seletor) ou um dos mecanismos de antiafinidade propostos (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Isso também é semelhante à atribuição de serviço VIP. Poderíamos fazer algo semelhante para serviços nominais. Um pod (ou modelo de pod) especificaria o pool de índices do qual deseja que um índice seja atribuído. Ao contrário dos serviços gerais, não esperamos que os pods precisem receber vários índices de pools diferentes. A atribuição seria registrada nas especificações do pod.
4. Prós: mais simples para os usuários. Não requer outro objeto. Permite atribuição por usuários.
5. Contras: Diferente de outros tipos de serviços.

A atribuição de PVC idealmente usaria o mesmo modelo.

Também vale a pena considerar como a migração do pod nº 3949 seria orquestrada. O pod de substituição DEVE ser criado antes de excluir o pod que está sendo substituído para transferir o estado do contêiner. Isso pode tornar o modelo pull um pouco problemático. Independentemente disso, o mecanismo de alocação precisaria ser informado sobre a migração.

Outras considerações:

1. Como comunicar o índice / identidade aos pares. DNS é a resposta óbvia.
2. Como comunicar o índice / identidade aos contêineres do pod. Variáveis ​​de ambiente, DNS reverso, ... O índice atribuído não mudará dinamicamente, embora a vinculação de DNS possa ser alterada enquanto o pod ainda existir. Eu gostaria de escolher um mecanismo que os aplicativos já esperam que funcione em outros ambientes e, como acontece com a discussão mais ampla da API descendente (# 386), não quero acoplar aplicativos a variáveis ​​de ambiente específicas do Kubernetes, mas o novo EnvVarSource e a substituição env var (# 7936) ajudaria a evitar isso.

Não concordo com o que você disse, mas vamos esperar para continuar essa discussão até depois de 1.0.

Revivendo este velho tópico para fazer uma pergunta. Existe algum interesse em uma política de nomenclatura do controlador de replicação? Nomenclatura especificamente nominal, conforme discutido acima, em que todos os pods controlados por este controlador de replicação teriam sufixos numerados, algo como 0001, 0002 ....

Um exemplo de caso de uso é um balanceador de carga nginx apontando para esses conjuntos de pods por nomes de domínio. Assim, à medida que os pods vêm e vão, espera-se que os nomes de domínio sejam sempre corrigidos de xxx-0001 a xxx-000N.

@ravigadde Leia meu último comentário sobre este problema: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

Encontrou esse problema ao tentar configurar um contêiner RabbitMQ. A persistência do Rabbit depende do nome do host, portanto, ter nomes de host variáveis ​​significa que você perderá o banco de dados Mnesia na reinicialização do contêiner.

Tentei remediar com a configuração da imagem (nome do host diretamente e Rabbit), variáveis ​​ENV e a API Downward. Não foi possível obter nenhum para resolver o problema - o Rabbit ainda pega o nome do pod gerado. Resolvendo temporariamente, trocando o uso de um Controlador de Replicação de acordo com a sugestão de

Se bem entendi, o pod rabbitmq (criado com um controlador de replicação) no exemplo celerey-rabbit perderá dados na falha do pod, mesmo se os dados estiverem armazenados em um disco permanente. Do doc da rabbitmq:

O RabbitMQ nomeia o diretório do banco de dados usando o nome do host atual do sistema. Se o nome do host for alterado, um novo banco de dados vazio será criado. Para evitar a perda de dados, é crucial configurar um nome de host fixo e resolvível.

Não há uma boa solução para isso agora, mas você pode criar um pod (não vinculado a um rc) com um disco permanente migrável. A ressalva é que o pod precisará ser reprogramado manualmente em certos casos de falha. Essa é a única maneira que consigo pensar para manter o nome do host estático.

Ou ao iniciar o link simbólico do diretório do nome do host para um local estável

Em 11 de julho de 2015, às 17:26, Mike Danese [email protected] escreveu:

Se bem entendi, o pod rabbitmq (criado com uma replicação
controlador) no clerey-coelho
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
exemplo irá perder dados em caso de falha do pod, mesmo se os dados forem armazenados em um
disco permanente. Do doc da rabbitmq:

O RabbitMQ nomeia o diretório do banco de dados usando o nome do host atual do
sistema. Se o nome do host for alterado, um novo banco de dados vazio será criado. Evitar
perda de dados é crucial para configurar um nome de host fixo e resolvível.

Não há uma boa solução para isso agora, mas você pode criar um pod (não
vinculado a um rc) com um disco permanente migrável, a ressalva sendo o pod
precisará ser reprogramado manualmente em certos casos de falha. Essa é a
única maneira que consigo pensar em manter o nome do host estático.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

Esse é um exemplo de porque o nome do host não deve ser derivado do nome do pod - # 4825

Para dar um leve chute:

Existem vários problemas fundamentais que precisam ser resolvidos:

1. Alguns componentes precisam ter uma identidade exclusiva por pod, vinculada ao armazenamento em disco
   
   
   
   1. Como um problema adicional, alguns deles (zookeeper em alguns casos) precisam que o nome do host seja resolvido e corresponda
   
   
2. Alguns componentes dimensionados precisam ter armazenamento persistente diferente por pod (os pods apontam para PVCs que diferem por pod, vinculados à identidade)
   
   
   
   1. Às vezes, esses volumes devem ser criados sob demanda em escala
   
   
   2. Às vezes, esses volumes devem ser reutilizados de um pool e não recriados
   
   
3. Alguns componentes podem escalar para dezenas de milhares de instâncias, onde o rastreamento de identidades individuais alocadas torna-se impraticável
   
   
   
   1. A maioria dos usos para nominal será provavelmente entre 2 a 7 instâncias de um pod (a maioria dos bancos de dados escalonáveis ​​atuais, a maioria das configurações multi-master fragmentadas)
   
   
4. Alguns componentes gostariam de não ter que implementar sua própria eleição principal, mas deixar a plataforma gerenciar isso tornando uma das identidades arbitrária (a identidade 1 se torna a principal)
5. Quando resolvermos esses problemas, os usuários ainda precisarão implementar alterações nos pods (por meio de implantações) e garantir que qualquer identidade seja preservada ou realocada.

Nem todos eles precisam necessariamente ser resolvidos na mesma solução. Por exemplo, acho que há uma diferença significativa entre identidade de cluster de pequeno porte (2-7) e identidade de cluster de grande escala (> 7). Por exemplo, no caso grande, esse software está menos preocupado com as lacunas ou tem um protocolo de consenso / associação existente. No caso pequeno, o software precisa de mais ajuda para estabelecer a identidade. Gostaria de separá-los em software nativo da nuvem (> 7) e software em cluster existente (2-7).

Eu concordo com 1a, 1b e 2a. 2b parece um problema diferente, embora talvez a solução possa reutilizar o mesmo padrão.

Acho que a escala (3) sugere principalmente que nossa solução alternativa de um serviço e RC por instância não é adequada, embora eu concorde com a distinção entre nativo da nuvem vs. não.

A escolha do mestre (4) pode ser tratada separadamente.

Também concordo com (5).

Acho que a maioria dos requisitos de design estão claros neste ponto.

Restantes questões de design:

I. Alocar VIPs ou permitir a mudança de IPs? Intimamente vinculado a isso está se os contêineres precisam ser capazes de descobrir seus próprios IPs por meio do Linux ou não, uma vez que os VIPs atualmente não podem ser descobertos por meio do sistema. Presumo que eles precisam ser capazes de descobrir seus IPs, mas podem usar a API descendente, como com o pod IP (# 12595). Permitir a mudança de IPs (devido ao uso de IPs de pod) implica em um limite para a taxa de mudança do IP, devido a TTLs de DNS e "bugs" de cache. Em algum momento, também pretendemos tornar os IPs de pod migráveis ​​(# 3949), de forma que a mudança de IPs não seria para sempre.

II. Empurre (para os frutos) versus puxe (dos frutos). Os serviços e os RCs são intencionalmente fracamente acoplados aos pods e, portanto, ambos usam o modelo "push". Os serviços nominais estariam mais intrinsecamente ligados à identidade do pod (embora não permanentemente - os pods devem ser substituíveis). Consequentemente, vejo menos motivação para o modelo push. Outros casos de alocação, como agendamento e esp. vinculação exclusiva, como declarações de volume persistentes para volumes persistentes, usa um modelo de solicitação / ack, também conhecido como "pull". Esse é atualmente o modelo que prefiro para serviços nominais.

Alguém tem opinião sobre (I)?

A eleição do mestre é # 1542 e está sendo discutida como parte da implementação de HA (por exemplo, # 12884).

Eu não sei o que você quer dizer com empurrar e puxar.

Eu reli a maior parte desta edição e estou convencido de que não há um único
solução. Vamos precisar de uma família de recursos para construir uma ponte para
esses tipos de aplicativos.

Estou começando com o axioma de que, uma vez que um pod está funcionando, você não pode realmente
mudar um pod em execução. Existem algumas exceções a isso (por exemplo, virtual
conteúdo do sistema de arquivos), mas as coisas que parecem importar (env vars, IP,
hostname) você fica preso com o que quer que comece.

Também estou começando com a afirmação de que o acoplamento fraco entre
O serviço e o Pod permanecem, fazendo com que essa coisa de que estamos falando não seja realmente um
Serviço. Os pods não sabem realmente quais serviços os oferecem. Se mudarmos
isso, não é mais um serviço.

Vou apenas fazer um fluxo de consciência e ver o que não fede.

Ideia 1: ThingPools e Patches.

Defina um novo objeto de API ou algo que permita definir um pool de
coisas. O que é uma coisa? Uma coisa é uma string (ou talvez um blob JSON) que
tem um tipo enumerado. Você pode criar um pool de coisas e essas coisas
são seus para usar. Os tipos de coisas incluem VUIDs (nomes de host), strings, VIPs.

Defina uma nova construção de API que pode ser passada para criar operações - um
correção. Um patch é instruções sobre como corrigir o objeto que está sendo
criado. Uma das opções de patch é "alocar de um ThingPool".

Para colocá-los juntos:

Defina um ThingPool {meatadata.name: my-quorum-hostnames, type: VUID,
autogenerate: 5,} // cria um pool de 5 VUIDs válidos

Defina um RC {réplicas: 5 ...}

Na criação do RC (POST) também envie um Patch: {what:
"podTemplate.spec.containers [*]. metadata.VUID", pool: "my-quorum-hostnames"
}

A operação POST aplicaria o patch ao RC - alocando um VUID
por contêiner do ThingPool. Sempre que um pod é morto e recriado,
o VUID é retornado ao pool e o próximo pod a ser iniciado o obterá.

Você pode usar isso para gerar um conjunto de strings ("0" a "99") e colar
aqueles em um env var. Você pode usar isso para alocar um pool de VIPs e
em seguida, atribua esses VIPs aos pods (seria um novo pod durável de recursos
IPs - não tenho certeza de como isso vai escalar :) Você pode gerar um pool de
PersistentVolumeClaim nomeia e corrige o volume de declaração que cada pod usa.

Essa ideia é imperfeita em muitos aspectos, mas acho que captura melhor o
ideia de um conjunto de vagens sem definir totalmente um conjunto de vagens.

Ideia 2: Definir um conjunto de pods. Não finja que é um serviço. É mais perto
para um trabalho Borg. É como um RC, mas atribui ordinalidade aos pods que
controles - números de fragmentos. Ele controla o pool de VUIDs (mas não queremos
nome do host para ser algo que os usuários possam definir, hmmm ...).

Achei que tinha mais ideias, mas não tenho. Estou lutando com abstrações
e implementações - é inútil definir uma abstração que não podemos
implemento. VIPs para nominais parece ótimo, mas acho que vai empurrar o
limites de iptables. Fornecimento de um conjunto de nomes de host estáveis ​​para um conjunto de pods
parece ser a coisa mais importante, com um conjunto de armazenamento para um conjunto de
vagens quentes em sua cauda.

Na terça-feira, 18 de agosto de 2015 às 19h28, Brian Grant [email protected]
escreveu:

Eu concordo com 1a, 1b e 2a. 2b soa como um problema diferente, embora
talvez a solução possa reutilizar o mesmo padrão.

Acho que a escala (3) sugere principalmente que nossa solução alternativa de um serviço e
RC por instância não é adequado, embora eu concorde com a distinção entre
nativo da nuvem vs. não.

A escolha do mestre (4) pode ser tratada separadamente.

Também concordo com (5).

Acho que a maioria dos requisitos de design estão claros neste ponto.

Restantes questões de design:

I. Alocar VIPs ou permitir a mudança de IPs? Intimamente ligado a isso é se
os contêineres precisam ser capazes de descobrir seus próprios IPs via Linux ou não,
visto que os VIPs atualmente não são detectáveis ​​por meio do sistema. Eu suponho que eles façam
precisam ser capazes de descobrir seus IPs, mas podem usar a API descendente, como
com pod IP (# 12595 https://github.com/kubernetes/kubernetes/pull/12595).
Permitir que os IPs mudem (devido ao uso de IPs de pod) implica um limite para a taxa
de mudança de IP, devido a TTLs de DNS e "bugs" de cache. Em algum ponto, nós
também pretendo tornar os IPs de pod migráveis, embora (# 3949
https://github.com/kubernetes/kubernetes/issues/3949), portanto, alterando IPs
não seria para sempre.

II. Empurre (para os frutos) versus puxe (dos frutos). Serviços e RCs são
intencionalmente fracamente acoplado a pods e, portanto, ambos usam o botão "push"
modelo. Os serviços nominais estariam mais intrinsecamente ligados à identidade do pod
(embora não permanentemente - os vagens devem ser substituíveis). Conseqüentemente, eu vejo
menos motivação para o modelo push. Outros casos de alocação, como
agendamento e esp. vinculação exclusiva, como reivindicações de volume persistentes para
volumes persistentes, use um modelo request / ack, também conhecido como "pull". Isso é atualmente
o modelo que prefiro para serviços nominais.

Alguém tem opinião sobre (I)?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

Provavelmente não quis dizer eleição oficial, como você pensa - mais que
ao construir uma funcionalidade em que um conjunto de instâncias precisa ser inicializado
(sem coordenar explicitamente) tendo apenas a instância que pensa que é
"1" conversar com outros pods geralmente é suficiente para inicializar um cluster. Um
exemplo é mongodb, onde você precisa iniciar o conjunto de réplicas - se pods
que pensam que são "2" ou "3" iniciados, você pode obter nos casos em que
iniciar uma divisão. Mas "1" pode iniciar-se com segurança a cada vez, e então
tente adicionar os outros membros (que têm estado persistente que podem usar para
determinar se eles já fazem parte de um cluster). Dependendo do
garantias fornecidas pelo serviço de identidade, você não pode realmente obter um
cluster bem-sucedido, mas você não precisa criar um pod separado fora para
inicialize seu serviço (embora isso também não seja terrível).

Na terça-feira, 18 de agosto de 2015 às 23h59, Brian Grant [email protected]
escreveu:

A eleição do mestre é # 1542
https://github.com/kubernetes/kubernetes/issues/1542 , e está sendo
discutido como parte da implementação HA (por exemplo, # 12884
https://github.com/kubernetes/kubernetes/pull/12884).

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

Clayton Coleman | Engenheiro-chefe, OpenShift

@smarterclayton É um aparte ao problema dos serviços nominais, mas não é seguro inicializar conforme você está descrevendo. Se "1" for reiniciado em uma nova máquina e por acaso não conseguir alcançar os nós existentes, ele será reiniciado e agora você tem dois mongodbs afirmando serem autorizados. Você precisa alterar a definição do job para remover a capacidade de inicialização após a conclusão da inicialização.

Como @thockin pode estar aludindo, acho que estamos combinando desnecessariamente vários recursos semelhantes, mas diferentes aqui - e estamos incluindo mais do que o estritamente necessário no nível k8s.

Vejo dois casos de uso bastante diferentes descritos acima - diferindo pela fonte da verdade:

_Prescritivo: _ "Quero N shards em execução e, se houver mais ou menos do que isso, faça alterações para trazê-los de volta para N."
_Descriptivo: _ "Eu quero apenas descobrir automaticamente todos os fragmentos disponíveis e deixe-me descobrir de alguma forma conforme eles vêm e vão."

Acho que são diferentes e devem ser descritos de maneira diferente (embora possam apresentar metadados semelhantes aos pods em execução).

A discussão também incorporou cercas de recursos e garantias de acesso único. Afaics, o _único_ caso em que isso precisa ser feito no k8s é a montagem de volumes persistentes remotos (porque a montagem do fs precisa ser feita fora do contêiner), e isso é muito fácil de fazer por meio de bloqueios de etcd se o serviço de volume remoto subjacente não Já forneci cercas internamente. Todos os outros casos podem ser tratados pelos próprios trabalhos do usuário, usando um serviço de bloqueio distribuído (ou acessando serviços que fornecem bloqueio internamente). Solicitar que as tarefas façam seu próprio bloqueio abre todos os tipos de padrões (atribuição fixa, atribuição oportunista, "sobressalentes", etc) e estratégias de inalcançabilidade / recuperação (falha grave, continuar com o último conhecido, etc).

Eu sugiro tirar a solicitação de recurso geral do fence de recursos deste bug (e nós implementamos o fencing simplesmente fornecendo uma receita para executar vários serviços de bloqueio distribuídos no k8s sem nenhum envolvimento adicional do próprio k8s).

Apenas um lembrete: há um _muito_ de portas atrás de um único VIP. Concordo que não queremos migrar IPs, pois isso parece difícil para a rede subjacente em escala e difícil para a rede lidar com duplicatas temporárias durante casos extremos de falha / recuperação. No entanto, acho que _é_ bastante viável atribuir uma porta de serviço exclusiva para cada membro de shard e dados de proxy para cada instância de pod - mesmo para trabalhos muito grandes. (Esta sugestão pressupõe que os proxies ainda são a direção que queremos ir com o k8s - não acompanhei nenhuma discussão recente sobre esta área)

Por push, quero dizer que outro recurso, como um serviço ou controlador, monitoraria conjuntos de pods por meio de um seletor de rótulo e conferiria "coisas" (nomes DNS resolvíveis, VIPs, PVCs) a eles.

Por pull, eu quis dizer que o pod solicitaria explicitamente a alocação de uma "coisa", que seria ligada a ele por meio de algo como / binding.

Com relação à alteração de pods em execução: alterar um pod após a criação é diferente de alterar um pod com contêineres em execução. O planejador executa de forma assíncrona. inicialização, por exemplo. O PodIP também é atribuído com atraso. Discutido de forma mais geral em # 3585.

Sobre se este é realmente um "serviço" ou não:

• As coisas precisam ser alocadas em conjuntos de pods
• Coisas (por exemplo, nomes DNS) não devem ser intrinsecamente vinculadas ao nome de recurso de um pod
• Algo precisa ser transferível de um pod para outro
• O pod precisa "saber" (ou ser capaz de descobrir por meio da API descendente) a que coisa (especialmente o nome DNS e VIP) foi atribuído.
• Uma coisa que precisamos oferecer suporte é o DNS resolvível
• Se precisamos de VIPs, era minha única pergunta pendente. Estou bem em não usar VIPs.
• Não é o ideal, mas o usuário pode criar um segundo serviço sem interface com o objetivo de todo o conjunto para descoberta de pares via DNS e / ou Endpoints.

Ideia (1), ThingPools + Patches é uma ideia interessante. Eu o descreveria como uma abordagem "puxada". ThingPool não é ruim, mas estou preocupado que os Patches sejam difíceis de usar, e eu não gostaria de fazer engenharia reversa das informações semânticas dos patches dentro do sistema para fornecer um comportamento aceitável em torno do ciclo de vida do armazenamento, etc. d prefiro algo mais específico do domínio. Além disso, ThingPools independentes para nomes DNS e PVCs não funcionariam, pois eles precisam ser co-alocados.

Eu descreveria a ideia (2) como uma abordagem "push". Não quero duplicar o trabalho em RCs e implantações, portanto, não devemos introduzir outro controlador de pod. Um atribuidor seria bom, mas é mais fracamente acoplado do que o necessário e não corresponde ao precedente de como lidamos com a atribuição.

Ré. colocando informações em env vars: Isso também surgiu para Jó. Quero colocar as informações em uma anotação e estender a API descendente para poder solicitar anotações específicas. Quero continuar a permitir que os usuários solicitem apenas as informações de que precisam e escolham os nomes de env.

Ré. atribuir portas diferentes para cada instância: Isso não funcionaria para muitos aplicativos legados e também não é compatível com o design do nosso sistema.

Ré. prescritivo: manter N em execução é o que ReplicationController faz.

Ré. descritivo: são serviços sem cabeça, que já existem.

Ré. bloqueio: Sim, é a API de lease que está em andamento.

O provisionamento de armazenamento está sendo discutido em # 6773 (push) e # 12450 (pull).

Agora é tarde demais, mas de alguma forma tentarei encontrar tempo para fazer uma proposta depois de dormir um pouco.

Observação rápida: serviços sem cabeça não alocam VIPs

Poderíamos desacoplar a alocação / atribuição da publicação do DNS. Ignorando como a alocação / atribuição acontece no momento, poderíamos ter um sabor especial de serviço sem cabeça que pegasse nomes de algum campo nos pods que representam o nome do host.

E os problemas de armazenamento local durável são relevantes: # 7562, # 1515, # 598

Mais atualizações rápidas, como geralmente faço outras análises de relações públicas:

Uma vantagem de usar um serviço é que não precisaríamos garantir que os nomes de host solicitados para pods fossem globalmente exclusivos, uma vez que o serviço abrangeria os nomes publicados no DNS.

Ré. alocação / atribuição: quero evitar adicionar mais tipos de modelo a ReplicationController, Deployment, Daemon, etc., e quero que o armazenamento e os nomes possam migrar entre controladores tão facilmente quanto entre pods (se for isso que o usuário quiser).

Em 19 de agosto de 2015, à 1h04, Angus Lees [email protected] escreveu:

@smarterclayton https://github.com/smarterclayton É um aparte para o
problema de serviços nominais, mas não é seguro inicializar enquanto você
descrevendo. Se "1" for reiniciado em uma nova máquina e não for possível
para alcançar os nós existentes, então ele irá reinicializar e agora você tem dois
mongodb está afirmando ser autoritário. Você precisa mudar de emprego
definição para remover a capacidade de bootstrap após bootstrapping é
completo.

É perfeitamente possível que você se sobreponha nesse caso - mas na maioria
casos, estamos falando sobre armazenamento persistente com bloqueios para que você bloqueie
de qualquer maneira, até que o gce / AWS liberou sua cerca e você foi capaz de anexar. assim
você sacrifica a disponibilidade na inicialização, mas não necessariamente no tempo de execução
(a menos que você esteja em um armazenamento sem vedação, caso em que concordo que não seria
seguro)

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

Em 19 de agosto de 2015, à 1h35, Angus Lees [email protected] escreveu:

Como @thockin https://github.com/thockin pode estar aludindo, eu acho
estamos combinando desnecessariamente vários recursos semelhantes, mas diferentes aqui

• e estamos incluindo mais do que o estritamente necessário no nível k8s.

Vejo dois casos de uso bem diferentes descritos acima - diferindo pela fonte
de verdade:

_Prescritivo: _ "Eu quero N shards em execução, e se houver mais ou menos
do que isso, em seguida, faça alterações para trazê-lo de volta para N. "
_Descriptivo: _ "Quero apenas descobrir automaticamente todos os fragmentos disponíveis e
deixe-me descobrir de alguma forma conforme eles vêm e vão. "

Eu acho que eles são diferentes e deveriam ser descritos de forma diferente (embora

eles podem apresentar metadados semelhantes aos pods em execução).

A discussão também incorporou cerca de recursos e acesso único
garantias. Afaics, o _único_ caso em que isso precisa ser feito dentro de k8s
(afaics) está montando volumes remotos - porque a montagem fs precisa ser feita
fora do contêiner. Todos os outros casos podem ser tratados pelos trabalhos do usuário
próprios, usando um serviço de bloqueio distribuído (ou acessando serviços que
fornecer bloqueio internamente). Solicitando que as tarefas façam suas próprias aberturas de bloqueio
todos os tipos de padrões (atribuição fixa, atribuição oportunista, "quente
sobressalentes ", etc) e estratégias de inacessibilidade / recuperação (falha grave,
continue-with-last-known, etc).

Eu sugiro mover a solicitação de recurso de fence de recursos gerais para fora deste
bug (e implementamos fencing simplesmente fornecendo uma receita para executar
vários serviços de bloqueio distribuídos em k8s sem envolvimento adicional de
a própria k8s).

Não acho que possamos separar o objetivo para executar certos tipos de
software fora - o design diz serviços nominais, mas os casos de uso que somos
descrever é reutilizar a identidade e o disco. Eu concordo, a esgrima é uma propriedade de
volumes - mas vinculando a aquisição de um volume a uma certa propriedade de
a instância do pod não é.

Apenas um lembrete: há um _muito_ de portas atrás de um único VIP. Eu concordo nós
não quero migrar IPs, pois isso soa difícil na rede subjacente
em escala, e difícil para a rede lidar com duplicatas temporárias
durante casos extremos de falha / recuperação. No entanto, acho que _é_ bastante viável
para atribuir uma porta de serviço exclusiva para cada membro do fragmento e dados de proxy para cada
instância de pod - mesmo para trabalhos muito grandes. (Esta sugestão está assumindo o
proxies ainda são a direção que queremos ir com k8s - eu não acompanhei
com qualquer discussão recente sobre esta área)

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

Uma ligeira mudança na ideia ThingPool + Patches de @thockin:

Template: lista de recursos + parâmetros e substituição. Consulte https://github.com/openshift/origin/blob/master/pkg/template/api/types.go para inspiração. Ref # 503, # 1743, # 4210, # 6487.

TemplatePool. Basicamente, ThingPool. Gera instâncias densamente indexadas de Template on demand, em vez de por contagem de réplicas.

Para diversão / consistência: o v2 ReplicationController pode replicar modelos arbitrários em vez de apenas pods. ref # 170 (mais ou menos). Talvez não seja necessário se toda a alocação for orientada pela replicação de pod.

A principal alternativa seria algo mais específico de domínio, focado em nomes de host e pools de PVC, mas pools separados para cada um não funcionariam. Um único pool precisaria ser capaz de alocar tuplas de nomes de host e (potencialmente vários) PVCs. Uma vantagem do TemplatePool é que alguém poderia usá-lo para alocar um serviço (talvez externo) por réplica, automatizando a solução atual do Zookeeper. Não sei se pode haver outros recursos que alguém gostaria de replicar de forma semelhante 1 para 1 com pods, mas dada a taxa de crescimento de nossa API, não aposto que não haverá.

@smarterclayton Para

Sim, há algo errado com gmail + github + iPhones.

Em quinta-feira, 20 de agosto de 2015 às 14h24, Brian Grant [email protected]
escreveu:

@smarterclayton https://github.com/smarterclayton FYI quando você responder
por e-mail com comentários inline, suas respostas são ilegíveis, tanto em
gmail e no github. No gmail, não há quebras de linha e no github existe
não há prefixos de citação, então sua resposta é difícil de separar do
texto sendo citado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Engenheiro-chefe, OpenShift

Tivemos um rápido bate-papo hoje, alguns destaques:

Falou sobre as três classes de aplicativos:

• Aplicativos que são aplicativos da web sem estado (funcionam apenas com RCs)
• Aplicativos em escala gigante que usam mestres externos e têm coerência existente
  protocolos (Cassandra, Infiniband) para lidar com o consenso
• Pequenos softwares em cluster, como Mongodb, rethinkdb, volt, etcd,
  clusters zookeeper, riak e redis, que precisam de alguns padrões para funcionar bem
  
  
  
  • Identidade única (normalmente)
  
  
  • Volume persistente exclusivo por instância que é reutilizado (geralmente)
  
  
  • Endereço IP estável ou nome DNS (comumente) - o nome DNS geralmente é um
    
    standin para endereço IP estável
  
  
  • Nome de host estável (raramente)
  
  

Hoje, você pode resolver identidade única e volume persistente tendo N
controladores de replicação, endereço IP estável com N serviços. Nós gostaríamos
para não exigir N RCs e serviços para alguns desses casos de uso.

Conversamos sobre as sugestões de Tim e Brian, sem uma ordem específica:

• TemplatePool é problemático porque o replicador precisa ter o
  autoridade para criar objetos em todo o cluster, e tem que saber
  onde cada endpoint da API está.
  
  
  
  • Você poderia ter um endpoint de modelo instanciado, mas ainda precisa
    
    resolver o problema de delegação de autoridade (com contas de serviço?)
  
  
  • Localizar objetos e restringir a permissão são coisas de longo prazo
  
  
• O campo "pod identity" também conhecido como vuid de que falamos - o argumento foi feito
  e geralmente concorda com que não precisa ser globalmente único, apenas
  único dentro do domínio que o pod espera usá-lo.
  
  
  
  • Um atribuidor de índice hipotético (esparso ou denso) poderia definir esse valor
    
    pós-criação, e o kubelet poderia esperar para iniciar os pods até que tivesse um
    
    identidade (pode ser necessário indicar que estão esperando por uma)
  
  
  • Índices densos são geralmente úteis para coisas simples, mas porque isso
    
    é a pós-criação e desacoplada do kubelet, você poderia ter diferentes
    
    tipos de algoritmos de atribuição (numérico denso, anel de hash consistente,
    
    aleatório, etc)
  
  
• Modelar modelos simples em pods parece um bom lugar para começar, mas precisamos
  para torná-lo consistente com nossa cadeia de ferramentas existente de uma forma que não
  quebrar totalmente
  
  
  
  • Use o campo de identidade para modelar outros campos
  
  
• Adicione um campo de nome de host na especificação do pod que os usuários possam definir e
  parametrizar com a identidade
• Permitir que um serviço sem comando responda a consultas de DNS para endpoints por seus
  identidade (faça com que o controlador de endpoints materialize a identidade de um pod
  em endpoints) que garante alguma estabilidade
• De alguma forma, permita que declarações de volume persistentes sejam parametrizadas ou alteradas para
  extrair de um pool (ou ter um controlador de pool para garantir que haja um volume por
  identidade, ou fazer com que o controlador de identidade extraia de pools), precisa ser pensado
• Precisa de ferramentas que tornem fácil transformar ambiente / API descendente em
  arquivos de configuração (ortogonais, mas devem ser mais fáceis)
• Ainda há algumas preocupações sobre o padrão

Em quinta- feira , 20 de agosto de 2015 às 15:34, Clayton Coleman
escreveu:

Sim, há algo errado com gmail + github + iPhones.

Em quinta-feira, 20 de agosto de 2015 às 14h24, Brian Grant [email protected]
escreveu:

@smarterclayton https://github.com/smarterclayton FYI quando você responder
por e-mail com comentários inline, suas respostas são ilegíveis, tanto em
gmail e no github. No gmail, não há quebras de linha e no github existe
não há prefixos de citação, então sua resposta é difícil de separar do
texto sendo citado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Engenheiro-chefe, OpenShift

Clayton Coleman | Engenheiro-chefe, OpenShift

Mais um problema: certificados TLS para membros de serviços nominais

Certificados TLS para serviços em geral também seriam uma coisa boa (assinado
pelo cluster CA automaticamente a pedido).

Em quinta-feira, 20 de agosto de 2015 às 17:19, Brian Grant [email protected] escreveu:

Mais um problema: certificados TLS para membros de serviços nominais

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Clayton Coleman | Engenheiro-chefe, OpenShift

Sim: # 11725

Ré:

• Adicione um campo de nome de host na especificação do pod que os usuários possam definir e
  parametrizar com a identidade
• Permitir que um serviço sem comando responda a consultas de DNS para endpoints por seus
  identidade (faça com que o controlador de endpoints materialize a identidade de um pod
  em endpoints) que garante alguma estabilidade

Acredito que concordamos que o dns deve ser compatível com o uso de nomes de host definidos nas especificações do pod (que podem ser parametrizados por suas identidades assim que adicionarmos essa funcionalidade), de forma que os nomes de host vistos pelos contêineres possam ser resolvidos por outros contêineres.

Para definir o subdomínio, teríamos que informar ao pod qual serviço o direcionava, explícita ou implicitamente. A desvantagem do explícito é que ele requer mais colagem / modelagem de configuração. A desvantagem do implícito é que ele estaria sujeito aos desafios que temos com o acoplamento fraco no sistema: disputas e inconsistências na ordem de criação, dificuldades de execução 1 para 1 etc. Eu me inclino para o explícito. Devemos apenas trabalhar para melhorar o escopo das referências cruzadas.

Algo como:

Hostname string
Subdomain string

acima HostNetwork no PodSpec.

Nós só entregaríamos o DNS baseado no nome do host se o subdomínio corresponder a um serviço do tipo certo. Também poderíamos compactar os dois em um único campo.

Acho que devemos reformular a edição 4825 para isso e pedir a alguém que trabalhe nisso. É muito mais concreto e menos trabalhoso do que o resto.

De alguma forma, permita que declarações de volume persistentes sejam parametrizadas ou alteradas para
extrair de um pool (ou ter um controlador de pool para garantir que haja um volume por
identidade, ou fazer com que o controlador de identidade extraia de pools), precisa ser pensado

Acho que duas coisas sobre reivindicações podem ajudar aqui:

1. Altere a ligação de 1: 1 para 1: N
   
   
   
   1. pvc.Spec.VolumeName para pvc.Spec.VolumeNames [] como a referência de ligação
   
   
2. pvc.Spec.Singelton booleano que indica se uma declaração deve ser vinculada exatamente uma vez para compartilhamento ou permite que a declaração seja vinculada várias vezes.

Um RC pode se ligar a novos volumes conforme necessário. Eu descobriria como lidar com isso no fichário.

Ainda assim, seria importante combinar o volume correto com o pod correto.

Você teria que ter um mapa de identidades para nomes de volume.

Na sexta-feira, 21 de agosto de 2015 às 15:17, Mark Turansky [email protected]
escreveu:

De alguma forma, permita que declarações de volume persistentes sejam parametrizadas ou alteradas para
extrair de um pool (ou ter um controlador de pool para garantir que haja um volume por
identidade, ou fazer com que o controlador de identidade extraia de pools), precisa ser pensado

Acho que duas coisas sobre reivindicações podem ajudar aqui:

1. Altere a ligação de 1: 1 para 1: N
   
   
   
   1. pvc.Spec.VolumeName para pvc.Spec.VolumeNames [] como a ligação
      
      referência
   
   
2. pvc.Spec.Singelton booleano que indica se uma declaração deve ser vinculada
   exatamente uma vez para compartilhar ou permitir que a reivindicação seja vinculada várias vezes.

Um RC pode se ligar a novos volumes conforme necessário. Eu descobriria como lidar com isso
no fichário.

Ainda assim, seria importante combinar o volume correto com o pod correto.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Clayton Coleman | Engenheiro-chefe, OpenShift

Na sexta-feira, 21 de agosto de 2015 às 12h56, Brian Grant [email protected] escreveu:

Para definir o subdomínio, teríamos que dizer ao pod qual serviço o direcionou,
explicitamente ou implicitamente. A desvantagem do explícito é que requer mais
colagem / modelo de configuração. A desvantagem do implícito é que seria
propenso aos desafios que temos com o acoplamento fraco no sistema: criação-
ordenar corridas e inconsistências, dificuldades de aplicação de 1 para 1, etc.
para explícito. Devemos apenas trabalhar para melhorar o escopo das referências cruzadas.

Vamos ser claros - se NÃO definirmos o subdomínio, não podemos permitir que os usuários forneçam
seus próprios nomes de host. Se definirmos o subdomínio, temos que fazer isso em um
forma que é única o suficiente (no espaço DNS, o que atualmente significa
o namespace). Fazer o subdomínio ser o nome de um serviço é
único o suficiente.

Dadas algumas das limitações do nosso DNS (um único TLD), este
realisticamente significa que damos aos usuários dois campos DNS_LABEL - nome do host
e nominal. Para um exemplo concreto:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

Isso resultaria no pod vendo:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

e DNS servindo registros A e PTR para foo.bar.my-app.nom.cluster.local

Este é um nível mais profundo do que nossa estrutura DNS atual, mas acho
nosso atual ndots = 5 cobre isso. Alternativamente, poderíamos dizer que um
namespace é o sobrenome e coloque-o de volta aos usuários para atribuir
nomes de host em um namespace. O resultado DNS seria
foo.my-app.pod.cluster.local que espelha os Serviços. Poderíamos até
torne-os mais semelhantes adicionando um campo opcional de nome de host aos serviços.

Nós só entregaríamos o DNS baseado no nome do host se o subdomínio corresponder àquele para
um serviço do tipo certo. Também poderíamos compactar os dois em um único campo.

Minha parte menos favorita disso é que o Pod está declarando "Eu sou parte
de serviço 'bar' "(no exemplo acima). Na frente. A priori.

A ladeira escorregadia é por que não permitir isso em geral? Seria
simplificar um monte de coisas que não podem fazer suposições hoje (porque
de acoplamento fraco), embora na prática raramente vejamos um único pod
por trás de mais de um serviço. Se cada pod estivesse abaixo de zero ou um
Serviço, o sistema fica mais simples?

Acho que devemos reformular a edição 4825 para isso e pedir a alguém que trabalhe nisso. É muito mais concreto e menos trabalhoso do que o resto.

Certamente é algo que pode começar imediatamente, mas (para aqueles
acompanhando em casa) é apenas o mecanismo para implementar o pod
identidade, não a política de gerenciamento de conjuntos de identidades.

Na sexta-feira, 21 de agosto de 2015 às 15:17, Mark Turansky [email protected] escreveu:

Acho que duas coisas sobre reivindicações podem ajudar aqui:

1. Altere a ligação de 1: 1 para 1: N

Foi aqui que comecei, mas ...

Na sexta-feira, 21 de agosto de 2015 às 12h38, Clayton Coleman
notificaçõ[email protected] escreveu:

Você teria que ter um mapa de identidades para nomes de volume.

Sim. Isso está realmente se tornando um problema de modelagem.
Se você pensa no problema como um "modelo de pod" em que alguns
campos têm marcadores que são preenchidos por uma "tupla de substituição"
retirado de um pool em tempo de execução ou você pensa que é um pod totalmente reificado
especificação que é "corrigida" com uma "tupla de substituição" retirada de um pool
em tempo de execução - eles são isomórficos e igualmente desagradáveis.

Mesmo assim, acho que este é um dos maiores problemas que precisamos resolver.
Devemos começar a elaborar propostas espantalho para isso?

Temos vários exemplos de pods em dois ou três serviços, um para
espalhar, um para exposição e um para testar a exposição.

Com relação à identidade, cada pod criado por um controlador daemon deve ter uma identidade atribuída que é derivada da identidade do nó e da identidade do controlador. Este pode ser um caso em que a identidade é óbvia (o pod x no host y tem a identidade f (y)) e parte da responsabilidade dos daemons.

@smarterclayton então uma necessidade comum (mas não universal) aqui é manter uma lista ordenada e estável de membros do grupo. Como isso pode funcionar quando a identidade está ligada ao nó em que o pod está programado?

O controlador daemon _somente_ tem identidade no contexto do nó em que o pod está
correr. Os controladores e serviços de replicação são diferentes. Daemon
controlador diz "deve haver um destes em execução em cada nó". Lá
não há outra identidade que o pod possa ter, exceto seu nó.

Na sexta-feira, 11 de setembro de 2015 às 01h13, Angus Lees [email protected]
escreveu:

@smarterclayton https://github.com/smarterclayton então um comum (mas não
universal) a necessidade aqui é manter uma lista ordenada e estável de grupos
membros. Acho que isso implica que a identidade _não_ deve estar ligada ao
nó em que o pod está programado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Clayton Coleman | Engenheiro-chefe, OpenShift

@smarterclayton ah, esse problema claramente se transformou em algo mais do que a solicitação de recurso original - estou perdido no que estava tentando construir aqui, então vou recuar em vez de continuar a adicionar ruído ...

Desculpe, não quis dar a entender que o ponto não era relevante. O desafio é que precisamos definir conjuntos e propagá-los para o pod. Precisamos que o pod seja reativo à associação no conjunto (monte o volume X que corresponda à identidade do pod no conjunto). Há uma questão em aberto - um pod poderia ser membro de dois conjuntos simultaneamente e ter uma identidade única em qualquer um deles?

Pode ser que os pods executados por um controlador daemon tenham uma identidade "óbvia" (o controlador daemon opera em um conjunto de nós, o RC opera em um conjunto de pods).

Um dos requisitos da identidade é que seja única no conjunto. Podemos aproveitar os nomes e a geração de nomes de pods para garantir essa exclusividade? Por exemplo, RCs geram nomes aleatórios. Um RC pode gerar nomes para os pods de maneira determinística com base no conjunto de pods que seleciona?

Considere um RC que seleciona pods com rótulo a = b. Para calcular o próximo pod a ser criado, ele deve buscar os pods e reduzi-los a uma contagem. E se o reduzíssemos a um conjunto de nomes exclusivo e, em seguida, o RC tentasse seguir um padrão de geração de nome dentro desse conjunto? Dois RCs que não se sobrepõem, mas criaram pods em um rótulo de serviço, não seriam capazes de gerar nomes exclusivos (eles podem lutar por um nome, mas isso está implícito). Os nomes podem ser reutilizados após serem excluídos

Então, os volumes persistentes no pod podem usar PVCs com base no nome do pod. Um pool de pvc pode garantir que haja reivindicações suficientes para um pool de RCs observado. O controlador daemon pode escolher nomes determinísticos para um nome de nó. Também podemos conectar nomes DNS a nomes de pod em um serviço com base em algum padrão.

Isso parece mais parcimonioso do que adicionar um campo de identidade distinto ao pod. Isso significa que vagens ainda não são animais de estimação, mas seus nomes podem ser (o que não é uma afirmação irracional). Não podemos evitar que duas instâncias do mesmo processo de pod sejam executadas no cluster ao mesmo tempo, mas podemos garantir (e fazemos) que o nome só está em uso em um lugar hoje.

Significa "pool observado de nomes" acima. Endpoint DNS seria hashpodname.ept.service.namespace.svc.cluster.local. Já temos o nome do pod no endpoint, então nem precisamos adicionar nada.

relacionado a https://github.com/kubernetes/contrib/tree/master/service-loadbalancer que propõe a resolução deste problema como uma possível próxima iteração

Por que estamos discutindo DaemonSet aqui? Isso foi resolvido por # 12893, IMO.

@smarterclayton Não vamos revisitar a derivação de identidade de nomes de pod, nem usar RCs para atribuir identidade. Problemas com essas abordagens foram discutidos aqui: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Uma possibilidade seria ter uma opção RC que permite gerar nomes da maneira que @smarterclayton descreveu, se desejar, e conjuntos distintos de recursos disponíveis para você, dependendo de como você definiu a opção. Portanto, o que é difícil de implementar com uma abordagem de "índice de tarefa" não estaria disponível se você habilitasse a opção, mas o recurso descrito aqui estaria. E, inversamente, o comportamento padrão (opção desabilitada) daria a você esses outros recursos, mas não o descrito aqui.

Parece que a utilidade de algo como a abstração do índice de tarefa Borg continua surgindo _para certos casos de uso_ e não está claro para mim por que não podemos oferecê-la como uma opção.

DaemonSet, não acho que resolva o caso de armazenamento do sistema de arquivos distribuído
(Gluster) onde cada hospedeiro precisa ter uma identidade consistente para reingressar
o cluster. Vou cavar mais, mas acho que ainda pode precisar de algo junto
as necessidades de # 260 - Não sei se o nome do host é suficiente se você reconectar
um disco host em uma nova instância. Talvez eu não tenha entendido o que DaemonSet
fornecido e # 12893 entregue, mas não acho que esse seja o problema para um
host do sistema que deseja reutilizar o disco.

Na quarta-feira, 16 de setembro de 2015 às 12h22, Brian Grant [email protected]
escreveu:

@smarterclayton https://github.com/smarterclayton Não vamos revisitar
derivar identidade de nomes de pod, nem usar RCs para atribuir identidade.
Os problemas com essas abordagens foram discutidos aqui: # 260 (comentário)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Engenheiro-chefe, OpenShift

Como um exemplo concreto, imagine um cluster etcd. Possui 7 instâncias e 7
volumes. Eu quero (por uma questão de argumento), os nomes e volumes etcd-1
por meio de etcd-7 e etcd-pvc-1 por meio de etc-pvc-7.

Uma implantação contínua tem MaxUnavailable 90% (ou equiv), MaxSurge 0%. Isto
reduz o RC antigo e aumenta o novo RC. O velho RC graciosamente
exclui o etcd-5. Ele sai instantaneamente do conjunto RC efetivo. O novo
O RC tenta criar o etcd-5 (observando a lacuna definida). Recebe um
"AlreadyExistsException". Ele trata isso como recuo e recolocação na fila. Uma vez
etcd-5 realmente se foi, ele pode continuar. Assim que o etcd-5 estiver pronto, o DC
passa para a próxima etapa.

Para a alternativa - identidade definida no pod - o RC antigo foi reduzido. UMA
novo pod é criado instantaneamente com um novo nome. O novo pod não pode ser iniciado
porque ele precisa de identidade definida para descobrir qual PVC montar para seu
volume. Ele entra em um loop de espera no Kubelet. O controlador de identidade
assiste algum seletor de etiqueta definido e observa a identidade etcd-5 não é
alocado. Ele define a identidade etcd-5 no novo pod. O kubelet observa
essa mudança e, em seguida, descobrir qual PVC montar, inicia o pod
(assumindo que o volume foi separado do outro nó).

Estruturalmente, eles são muito semelhantes. O último permite a sobreposição de início.
Ambos requerem o mapeamento do PVC.

Na quarta-feira, 16 de setembro de 2015 às 12h39 , Clayton Coleman
escreveu:

DaemonSet, não acho que resolva o caso de armazenamento do sistema de arquivos distribuído
(Gluster) onde cada hospedeiro precisa ter uma identidade consistente para reingressar
o cluster. Vou cavar mais, mas acho que ainda pode precisar de algo junto
as necessidades de # 260 - Não sei se o nome do host é suficiente se você reconectar
um disco host em uma nova instância. Talvez eu não tenha entendido o que DaemonSet
fornecido e # 12893 entregue, mas não acho que esse seja o problema para um
host do sistema que deseja reutilizar o disco.

Na quarta-feira, 16 de setembro de 2015 às 12h22, Brian Grant [email protected]
escreveu:

@smarterclayton https://github.com/smarterclayton Não vamos revisitar
derivar identidade de nomes de pod, nem usar RCs para atribuir identidade.
Os problemas com essas abordagens foram discutidos aqui: # 260 (comentário)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Engenheiro-chefe, OpenShift

Clayton Coleman | Engenheiro-chefe, OpenShift

O que torna esse problema difícil, para mim, não é gerar um pool único e estável de nomes ou usar um pool de PDs. O problema é fazer AMBOS ao mesmo tempo. E se você estender isso, por que qualquer identificador na especificação não pode ser agrupado dessa forma?

Tanto quanto eu sei (principalmente de segunda mão) os problemas com índices compactados, eu acho que eles podem ser habitáveis ​​(especialmente se fizermos como David sugere e torná-los mutuamente exclusivos com outros recursos). Mas também, quanto mais penso nisso, menos odeio a ideia do Patch que algum idiota postou no tópico.

Este problema persistiu e persistiu e temo que tenhamos paralisado a análise.

Gostaria de ter mais exemplos de outros casos de uso de pool. Eu pensei gluster
seria diferente, mas é apenas outra variante do
cassandra / etcd / mongo / zookeeper "quero reutilizar um volume e preciso
lembro quem eu disse que era antes ". Nós realmente não tivemos um papel baseado (eu
quero fazer os primeiros N coordenadores de pods e os próximos M trabalhadores) exemplo
para alavancar.

Na quarta-feira, 16 de setembro de 2015 às 12h46, Tim Hockin [email protected]
escreveu:

O que torna esse problema difícil, para mim, não é gerar um estábulo
pool exclusivo de nomes ou usando um pool de PDs. O problema é fazer AMBOS em
o mesmo tempo. E se você estender isso, por que não pode qualquer
identificador na especificação ser agrupado assim?

Tanto quanto eu sei (principalmente de segunda mão) os problemas com índices compactados, eu
acho que eles podem ser habitáveis ​​(especialmente se fizermos como David sugere e fizermos
eles são mutuamente exclusivos com outros recursos). Mas também, quanto mais eu penso
menos odeio a ideia do Patch que algum idiota postou no tópico.

Este problema persistiu e persistiu e temo que tenhamos uma análise
paralisia.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Clayton Coleman | Engenheiro-chefe, OpenShift

DaemonSet:

12893 definir o nome do host do pod para o nome do host do nó ao usar a rede do host, o que é totalmente razoável de usar para DaemonSet, já que eles usariam hostPort de qualquer maneira.

Além disso, a intenção é integrar o DaemonSet com o controlador de nó para fornecer perdão indefinido implícito # 1574 e para habilitar o "agendamento" antes de o agendamento ser ativado para nós em geral. A priorização implícita também pode ser razoável.

Para um sistema de armazenamento em cluster, eu poderia imaginar o provisionamento de discos adicionais em cada host que são acessados ​​via hostPath apenas pelo sistema de armazenamento - eles não seriam usados ​​pelo Docker nem pelo emptyDir.

Com relação à identidade, não vejo nenhum problema com a proposta aqui: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Este problema perdurou principalmente devido à falta de prioridade suficiente, IMO.

Para fazer um riff sobre Clayton (ou talvez apenas para dizer as mesmas coisas, mas mais idiota):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

A implicação é que o RC (ou algo assim) percebe que este é um conjunto de identidade, atribui um índice da identidadePool, atribui essa identidade ao nome do pod e, em seguida, espia dentro para ver se algum outro campo centrado na identidade está definido - a identidade volume neste caso.

Não é totalmente genérico (você não pode agrupar nenhum campo aleatório), mas podemos adicionar mais opções de identificação conforme necessário

Tenho a sensação de que, se definirmos uma especificação de que gostamos nisso, isso pode ser feito mais cedo ou mais tarde.

Até mesmo escrever uma especificação leva tempo.

Com relação a IdentityPool / VolumePool, já decidimos há muito tempo que vários pools não funcionarão.

O prazo de conclusão do código 1.1 é sexta-feira. Podemos, por favor, não fazer isso agora?

Também relacionado: # 170. Isso propôs apenas dividir o modelo de pod, mas se escolhermos um esquema de modelagem (que eu prefiro fortemente a patch), devemos considerá-los juntos.

Eu coloquei pelo menos o design no v1.2-candidate.

Desculpe, não fui claro em meu esboço - o RC (ou IC?) Tem um conceito de
pool ou índice primário. Uma vez que um pod é atribuído a um índice no IC, que
index é usado para indexar em todos os campos centrados em pool.

Se dividirmos o modelo, presumo que o RC não pode
alterar o modelo. Isso é um pouco mais complicado.

Estou bem para parar de falar sobre isso esta semana. Simplesmente apareceu no meu
inbox e eu estávamos ruminando essa ideia ...

Na terça-feira, 15 de setembro de 2015 às 22h09, Brian Grant [email protected]
escreveu:

Até mesmo escrever uma especificação leva tempo.

Com relação ao IdentityPool / VolumePool, já decidimos há muito tempo
atrás, que vários pools não funcionam.

O prazo de conclusão do código 1.1 é sexta-feira. Podemos, por favor, não fazer isso agora?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Sim, houve apenas coisas que desencadearam discussões do nosso lado.
Os problemas do cliente não aguardam nenhum processo de liberação.

Na quarta-feira, 16 de setembro de 2015 às 01h14, Tim Hockin [email protected]
escreveu:

Desculpe, não fui claro em meu esboço - o RC (ou IC?) Tem um conceito de
pool ou índice primário. Uma vez que um pod é atribuído a um índice no IC, que
index é usado para indexar em todos os campos centrados em pool.

Se dividirmos o modelo, presumo que o RC não pode
alterar o modelo. Isso é um pouco mais complicado.

Estou bem para parar de falar sobre isso esta semana. Simplesmente apareceu no meu
inbox e eu estávamos ruminando essa ideia ...

Na terça-feira, 15 de setembro de 2015 às 22h09, Brian Grant [email protected]
escreveu:

Até mesmo escrever uma especificação leva tempo.

Com relação ao IdentityPool / VolumePool, já decidimos há muito tempo
atrás, que vários pools não funcionam.

O prazo de conclusão do código 1.1 é sexta-feira. Podemos, por favor, não fazer isso
agora?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Clayton Coleman | Engenheiro-chefe, OpenShift

A discussão é toda sobre números de IP e Pods, mas na minha experiência com Mongo & Zookeeper o IP dos Pods deve permanecer irrelevante (não se tornar animais de estimação). O _volume_ persistente precisa de um número nominal, pois esse volume registra o número IP dos outros 'volumes'. Qualquer pod que monte esse volume deve ser capaz de usar esse número IP gravado de alguma forma. O volume é o bichinho ...

Um nome DNS constante no tempo para um volume e atribuído a um pod que monta o volume percorrerá um longo caminho, eu acho.

A alteração da associação do conjunto no Mongo & ZK sempre exigirá a execução de um código personalizado e espero que seja o mesmo para a maioria dos outros conjuntos. Portanto, controlador de replicação é o nome errado, esses animais de estimação precisam mais de um controlador de navio membro. Um controlador de navio membro deve ser capaz de lidar com a configuração inicial e, em seguida, alterações incrementais nos conjuntos e, finalmente, eliminá-lo.

Dado um nome DNS constante com base no volume montado e a possibilidade de lidar com a associação do conjunto com código personalizado, acho que seria possível lidar com esse tipo de sistema.

Sim, o pod IP é mais um hack de curto prazo.

Para onde essa proposta está indo é algo acima de DNS e volume que ambos
pode alavancar para permanecer acoplado. A preocupação é que o volume que define o nome DNS
é o reverso do acoplamento que já estabelecemos, e também
quero permitir que outras partes da especificação do pod aproveitem esse conceito superior
(identidade) como a API descendente no ambiente. Isso torna a adaptação
identidade para software de conjunto diferente mais fácil (reduz o código personalizado por
modelo).

Precisamos ainda garantir que não haja um caso de uso além de conjuntos que
se sobrepõe aqui (não ouvi nenhuma sugestão) e, em seguida, tente chegar a um
proposta concreta que parece mínima e apropriada. Tim eu acho que tem
resumiu isso mais recentemente aqui.

Em 23 de setembro de 2015, às 11h33, Peter Kriens [email protected] escreveu:

A discussão é toda sobre números de IP e pods, mas em minha experiência com
Mongo & Zookeeper o IP dos Pods devem permanecer irrelevantes (não se tornarem animais de estimação).
O _volume_ persistente precisa de um número nominal, uma vez que este volume registra
o número IP dos outros 'volumes'. Qualquer pod que monte esse volume
deve ser capaz de usar esse número de IP gravado de alguma forma. O volume é o
bicho de estimação ...

Um nome DNS que é constante no tempo para um volume e atribuído a um pod que
monta o volume percorrerá um longo caminho, eu acho.

Mudar a associação do conjunto no Mongo & ZK sempre exigirá customização
código a ser executado e espero que seja o mesmo para a maioria dos outros conjuntos. assim
Controlador de replicação é o nome errado, esses animais precisam de mais um membro
Controlador de navio. Um controlador de navio membro deve ser capaz de lidar com o
configuração inicial e, em seguida, mudanças incrementais para os conjuntos e, finalmente,
mate-o.

Dado um nome DNS constante com base no volume montado e a possibilidade de
lidar com a associação do conjunto com código personalizado deve tornar possível
lidar com esse tipo de sistema, eu acho.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/ ping

Você pode encontrar um exemplo de configuração de um cluster ZK no Kubernetes usando os recursos existentes em https://hub.docker.com/r/elevy/zookeeper/. O principal requisito são endereços IP e nomes de host estáveis ​​para os membros do conjunto. Isso é feito usando serviços individuais para cada membro do cluster. O único problema é que, por padrão, o ZK tentará se vincular ao IP para o qual seu nome de host resolve, mas isso pode ser evitado por meio de um parâmetro de configuração.

@smarterclayton @thockin

Pensamentos enquanto ia de bicicleta para o escritório há alguns dias:

Atualmente estou pensando nisso como um controlador PetSet, ou talvez um controlador ShardSet, se as pessoas quiserem pensar nisso dessa forma, conforme discutido no início: https://github.com/kubernetes/kubernetes/issues/260# issuecomment -57671926.

O caso que estamos tentando abordar é onde existem N animais de estimação semelhantes, mas eles ainda são animais de estimação - eles não são fungíveis.

Ainda acho que amarrar isso ao ReplicationController não pode funcionar, em parte porque ReplicationController tem apenas um único modelo. PetSet / ShardSet precisa ser uma abstração de nível superior, mais como Deployment ou DaemonSet. PetSet poderia gerar potencialmente um objeto PodTemplate por instância.

Não acho que podemos simplesmente reutilizar a API Deployment. Entre outras coisas, a estratégia de implementação de atualização contínua agora em kubectl e implantação não funcionará neste caso. A maioria dos animais de estimação provavelmente desejaria atualizações de Recriar, e qualquer um que desejasse atualizações contínuas não seria capaz de lidar com qualquer pico acima de sua contagem de fragmentos e seria específico sobre a ordem de atualização.

Por mais que eu goste da ideia, não acho que a alocação de identidade de baixo para cima vá funcionar. Muitas condições de corrida com o retorno de identidades alocadas ao pool versus alocação de novas. Muito parecido com os problemas que o @erictune encontrou ao explorar o uso do RabbitMQ com Job.

Não quero representar a escala do PetSet em mais de um lugar, como em um controlador e em um pool de identidade, ou em um controlador e em um serviço, pois isso tornaria o dimensionamento complicado / estranho.

Não acho que precisamos de modelos de uso geral para este caso. Precisamos apenas eliminar pods com armazenamento associado e identidades de rede previsíveis e duráveis. O equivalente aproximado foi suficiente em Borg. Portanto, estou me inclinando fortemente para algo na linha de # 12450, mas no modelo de pod, e não nos próprios pods. Talvez uma matriz de persistentVolumeClaimTemplates além de um podTemplate. Não quero adicionar substituições sofisticadas para todas as fontes de volume específicas do provedor de nuvem, especialmente porque queremos descontinuá-las de qualquer maneira. Adicionar requisitos e / ou seletores adicionais aos PVCs deve ser suficiente. Também precisaremos ser capazes de provisionar volumes persistentes de alguma forma em algum ponto.

Ainda precisaremos fazer algo sobre o armazenamento local, eventualmente, mas acho que é separável.

E então o nome do host e o serviço sem comando mudam mencionados acima, aqui:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Trabalhando em uma proposta agora, terá um rascunho em breve.

A proposta está em https://github.com/kubernetes/kubernetes/pull/18016

... então onde estamos com PetSet?

Estou construindo soluções de banco de dados HA com base no Kubernetes. Alguns, principalmente bancos de dados de mestre único, exigem serviços com endpoints que mapeiam para pods específicos com base em eventos desses pods. Por exemplo:

1. O serviço "postgres" mapeia o round-robin para todos os pods no ReplicaSet, mas o serviço "postgres-master" mapeia para apenas um pod.
2. o pod mestre morre.
3. failover acontece. Como parte do failover, o novo mestre atualiza o Kube-master por meio da API para "pegar" o serviço postgres-master.
4. Ao fazer isso, todas as conexões anteriores com o postgres-master são encerradas.

@jberkus o código alfa inicial para habilitar PetSets foi mesclado ou está pendente de mesclagem. @ingvagabund da minha equipe vai começar a reunir exemplos que fazem uso do PetSet para ver o que funciona bem e o que ainda precisa ser melhorado. Recomendo que você entre em contato com ele se tiver alguns casos de uso específicos que deseja reunir e testar.

@ncdc Tudo foi feito para isso na v1.3? Não está claro porque a proposta não foi mesclada e não houve outros PRs fazendo referência a isso por algum tempo.

@bprashanth ^

Estamos pousando e2es e continuando a trabalhar em exemplos. Está em alfa
agora, mas a proposta vai passar pela primeira rodada de feedback alfa
antes de mesclar.

Em 19 de maio de 2016, às 10:25, Brandon Philips [email protected]
escreveu:

@ncdc https://github.com/ncdc Tudo foi feito para isso na v1.3? Isto é
pouco claro, pois a proposta não foi mesclada e não houve outros PRs
referenciando isso por um tempo.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

Onde posso encontrar documentos para isso? Eu gostaria de testá-lo para um caso de uso de failover de banco de dados.

Ah ha, exatamente o que precisamos de um especialista em postgres :)

veja https://github.com/kubernetes/contrib/pull/921 para exemplos, posso responder a quaisquer perguntas sobre prototying [db of choice] como petset. Temos vários esboços sob o rótulo "apps / stateful" (por exemplo: https://github.com/kubernetes/kubernetes/issues/23790, @philips um exemplo etcd seria ótimo). Eu não escrevi documentos ainda, farei isso nas últimas semanas de 1.3 (ainda 5 semanas para lançar depois que o código for concluído na sexta-feira).

Suponho que você tentará automatizar o failover com postgres, já que isso é bastante comum. Admito que atualmente isso ainda não é tão fácil quanto eu gostaria, você provavelmente precisa de um cão de guarda. @jberkus Eu gostaria de ouvir comentários sobre quais padrões tornam isso mais fácil.

Para dar uma revisão rápida, o petset hoje oferece uma identidade de rede consistente (DNS, nome do host) que corresponde a um volume montado na rede e garantias de pedidos. Portanto, se você criar um petset com replicas: 3 , você obterá:
serviço que rege: * .galear.default.svc.cluster.local
mysql-0 - volume0
mysql-1 - volume1: não começa até 0 estar rodando e pronto
mysql-2 - volume2: não começa até 0, 1 está funcionando pronto

Os pods podem usar DNS para descoberta de serviço, procurando registros SRV inseridos no serviço governante. É isso que este pod simples faz: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. Portanto, se você usar o localizador de pares por meio de um contêiner init como nos exemplos acima, mysql-1 não iniciará até que o contêiner init veja (mysql-1, mysql-0) no DNS e escreva a configuração apropriada.

Os volumes são provisionados por um provisionador dinâmico (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), então, se você não tiver um executando em seu cluster, mas deseja apenas prototipar, você pode simplesmente usar emptyDir. O caso "data-gravity" (https://github.com/kubernetes/kubernetes/issues/7562) ainda não funciona, mas funcionará eventualmente.

Acrescentarei que atualmente é mais fácil entregar a notificação "na inicialização" com uma lista de pares, por meio de contêineres de inicialização. É claro que também exigimos notificações de "mudança". Atualmente, para notar mudanças na associação do cluster, você precisa usar um pid1 customizado. Os namespaces pid compartilhados podem tornar isso mais fácil, já que você pode usar um arquivo secundário, também é algo que precisa funcionar.

Eu tenho um watchdog, é o failover do serviço que é mais complicado do que eu gostaria. Vai testar, obrigado!

Também preciso oferecer suporte ao etcd, portanto, pode haver muitos testes no futuro.

@ncdc Qual é o status do código alfa para isso? Eu gostaria de começar a testar / implementar. Precisamos implantar um cluster cassandra muito em breve aqui. Posso fazer isso com a base de código existente, mas seria bom testar as coisas do petset.

Você pode obtê-lo se construir a partir do HEAD

@bprashanth foi incorporado ao

https://github.com/kubernetes/contrib/tree/master/pets

yaml embutido em strings de anotação? oof, ai :(. obrigado, entretanto, investigarei como fazer um conjunto de cassandra.

isso é json. É um recurso alfa adicionado a um objeto GA (contêineres de inicialização em pods).
@chrislovecnm está trabalhando em Cassandra, talvez queira apenas esperá-lo.

@paralin aqui é o que estou trabalhando. Não há tempo para documentar e colocá-lo no repo k8s agora, mas esse é um plano de longo prazo. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra Está trabalhando para mim localmente, no HEAD.

A imagem C * mais recente na demonstração funciona bem.

Temos um problema aberto para mais documentação. Piscadela piscadela, knudge @bprashanth

Exemplo de PetSets com cluster etcd [1].

[1] https://github.com/kubernetes/contrib/pull/1295

Certifique-se de capturar as perguntas do projeto no documento da proposta depois de concluir a revisão

Em 30 de junho de 2016, às 01h25, Jan Chaloupka [email protected] escreveu:

Exemplo de PetSets com cluster etcd [1].

[1] kubernetes / contrib # 1295
https://github.com/kubernetes/contrib/pull/1295

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
ou silenciar o tópico
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

os documentos do petset são https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md e https://github.com/kubernetes/kubernetes.github. io / tree / release-1.3 / docs / user-guide / petset / bootstrapping , pretendo encerrar este problema e abrir um novo que aborda a mudança de petset para beta, a menos que alguém se oponha

https://github.com/kubernetes/kubernetes/issues/28718