@lavalamp Eu criei isso para tentar ter um lugar onde possamos pelo menos consolidar nossos pensamentos e acompanhar o progresso em recursos de terceiros. Tentei criar uma lista de deficiências conhecidas a serem resolvidas antes da promoção para estável.

Não tenho um proprietário em mente, mas o reconhecimento do problema parece estar na primeira etapa.

@ deads2k Estou aprendendo recursos de terceiros recentemente, também desejo ajudar em algo.

@ deads2k Estou aprendendo recursos de terceiros recentemente, também desejo ajudar em algo.

Reorganizei a lista em termos do que considero uma prioridade tática. As pessoas estão tentando usar isso agora e esses problemas vão queimar muito.

Se você se sentir confortável com o item "múltiplos recursos", isso seria um ótimo começo. Você pode criar um problema separado e podemos conversar sobre a implementação nele.

@ deads2k Passei algum tempo tentando reproduzir o primeiro problema:

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

mas com azar. Abaixo estão minhas etapas de reprodução:

1. crie um recurso de terceiros personalizado e espere que ele apareça

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. após um momento (mais de 10s), crie outro recurso de terceiros personalizado

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. verifique se ambos os recursos existem

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

parece que já oferecemos suporte a vários recursos, versão única.

E eu dou uma olhada profunda no código relacionado ao TPR. O thirdparty_controller sincronizará periodicamente (a cada 10 segundos), instalará a cada novo TPR e também fará algum trabalho de exclusão. O ThirdPartyResourceServer contém todos os mapeamentos TPR instalados. Como podemos ver em SyncOneResource e InstallThirdPartyResource , mesmo este grupo existe, ele ainda irá atualizar o grupo com a nova API.

Também descobri que sou capaz de excluir um esquema TPR de definição mesmo que haja instâncias de TPR no sistema. Eu acho que isso não deveria ser permitido.

@ deads2k Passei algum tempo tentando reproduzir o primeiro problema:

Tente habilitar este teste: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Se funcionar, estamos bem. Se falhar, algo está errado.

@ deads2k Oi David, por favor, dê uma olhada na mensagem que enviei no Slack. Além disso, adicionei uma correção para o teste de integração com falha, o controlador de recursos de terceiros removerá o gerenciador de rotas correspondente quando um TPR for excluído, isso ajudará no teste de integração, mas não tenho certeza se isso trará outros problemas .

Para o problema nº 1, ele foi corrigido aqui:

https://github.com/kubernetes/kubernetes/pull/28414

@brendandburns na verdade não, você pode executar o teste de integração comentar e ele irá falhar.

@brendandburns Mais corretamente, oferecemos suporte a vários recursos, versão única, mas a lógica de exclusão tem alguns problemas.

@AdoHe você

@brendandburns você pode ver aqui:

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

habilite este teste e você verá que ele falhará. Tentei consertar isso no meu local e abrirei um PR ainda hoje.

@brendandburns Infelizmente não registrei um problema.

Também ref https://github.com/kubernetes/kubernetes/issues/32306 (TPR deve ser excluído quando o namespace é excluído)

@ deads2k você pode atualizar a lista de verificação?

@ deads2k você pode atualizar a lista de verificação?

Todas as questões ainda pendentes. Na verdade, este é um recurso para rastrear os problemas na implementação (já) beta thirdparyresources de 1.3. Precisávamos de um lugar para controlar nossos problemas, mas tínhamos que dedicar energia a outros esforços no 1.5.

@ deads2k Já estou trabalhando em Multiple Resources, single version e Multiple versions , acho que muitos códigos precisam ser atualizados.

@ deads2k ainda apresenta o alvo 1.5?

@idvoretskyi Receio que não :(

@ deads2k : ThirdPartyResources deve ser adicionado às APIs federadas.

@ deads2k : Atualmente os seletores de campo não estão funcionando ao consultar ThirdPartyObjects, isso é algo para a sua lista?

@ deads2k @rmohr kubectl ainda tem muitos recursos pendentes contra o TPR, a lista acima deve ser atualizada para rastreá-los.

@ deads2k : Atualmente os seletores de campo não estão funcionando ao consultar ThirdPartyObjects, isso é algo para a sua lista?

Esse é um problema mais geral de suporte ao seletor de campo inconsistente em todos os tipos de API.

Estou começando a olhar para isso também. ThirdPartyResources são muito importantes para dar suporte a controladores "externos" como o spark , e antes que possamos adicionar coisas como sub-recursos, devemos consertar isso.

Os seletores de campo funcionam apenas em campos selecionados manualmente nos objetos regulares da API. Eu não esperaria que eles funcionassem para quaisquer campos em TPRs - o apiserver não foi construído para fazer consultas arbitrárias. Se você precisa desse comportamento, o TPR não funcionará para você.

A próxima etapa é mover os TPRs para um servidor API adicional ?
Parece que existem alguns PRs pendentes para corrigir alguns dos problemas na lista aqui que podem estar bloqueados neste item.

/ cc @liggitt @ deads2k @AdoHe

Para diminuir a complexidade dos TPRs no código apiserver e tornar a lógica do TPR muito mais explícita, eu definitivamente votaria em um tpr-apiserver autônomo. Mas, IMO, isso realmente não bloqueia nenhuma das correções.

Estou adicionando alguns itens sobre como lidar com a semântica da API (get, list, watch, update, patch) ao lidar com vários tipos não conversíveis. Eu acho que provavelmente precisa de um documento de design, uma vez que a semântica provavelmente não corresponderá à semântica normal da API.

Vou dar (mais uma) corrida para consertar alguns desses problemas ...

https://github.com/kubernetes/kubernetes/pull/40260 e https://github.com/kubernetes/kubernetes/pull/40096 nos colocará em uma boa forma no lado do kubectl

O problema mais grave do lado do servidor no momento é o coletor de lixo perdendo a cabeça com os ownerRefs que apontam para os TPRs.

Depois de resolver isso, devemos decidir qual deve ser a semântica da API em torno de várias versões de um determinado TPR e ter certeza de que o tipo de TPR tem os dados de que precisamos. Isso provavelmente afetará o implemento de armazenamento do lado do servidor, então prefiro acertar o projeto antes de fazermos muito trabalho do lado do servidor.

@liggitt Vou dar uma olhada na revisão deles. valeu

Alguém tem uma indicação de como se referir a TPRs nas regras de RBAC? Eu tenho um TPR chamado foo-bar.something.example.com. Como administrador de cluster, posso obter uma lista de foobars em um determinado namespace com kubectl get foobars .

Quando um usuário normal tenta a mesma coisa, ele recebe Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

Eu tentei todas as variações de foobar, foo-bar, etc. que eu posso pensar em uma regra RBAC sem sorte até agora.

Na regra, você está procurando resource = foobars apigroup = something.example.com verb = get, list, watch

@ deads2k Isso funcionou. Obrigado!

@liggitt

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

algo relacionado com o problema de limpeza do TPR?

Não, era um problema com o coletor de lixo não saber como consultar ownerRefs para qualquer coisa diferente de compilados em tipos. O problema inverso também existe, com o coletor de lixo não prestando atenção aos finalizadores em nada além dos tipos compilados.

Ambos os problemas do coletor de lixo são distintos da necessidade de limpar objetos ThirdPartyResourceData de forma confiável quando o objeto ThirdPartyResource é removido.

@liggitt Obrigado pela explicação paciente, então qual é o plano do TPR no 1.6?

O GC agora registra apenas 1 mil vezes por segundo em vez de 50 mil vezes por segundo,
então ele não ganha mais a corrida com o rotador de toras. Mas uma solução real será
em breve, espero.

No sábado, 4 de fevereiro de 2017 às 23h54, TonyAdo [email protected] escreveu:

@liggitt https://github.com/liggitt Obrigado pela explicação do paciente, então
qual é o plano do TPR em 1.6?

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

Algumas das questões em aberto relacionadas ao TPR. Não exaustivo.

Problemas de grupo / versão: https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
Assista: https://github.com/kubernetes/kubernetes/issues/25340
Link próprio: https://github.com/kubernetes/kubernetes/issues/37622
Exclusão de namespace: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
Finalizadores: https://github.com/kubernetes/kubernetes/issues/40715
Limpeza de dados TPR: https://github.com/kubernetes/kubernetes/issues/35949
Validação mais forte de metadados: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
Falta de testes de unidade: https://github.com/kubernetes/kubernetes/pull/40956
Limpeza: https://github.com/kubernetes/kubernetes/issues/36998

Recursos que os usuários acham que são bugs porque funcionam para outros recursos:
Comportamento assíncrono: https://github.com/kubernetes/kubernetes/issues/29002
Inteiros: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
Saída decente do kubectl: https://github.com/kubernetes/kubernetes/issues/31343
Simplifique a nomenclatura de recursos: https://github.com/kubernetes/kubernetes/issues/29415
Inscreva-se: https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
Editar: https://github.com/kubernetes/kubernetes/issues/35993

/ cc

Inscrevendo-se porque estamos tentando lidar com TPRs no Dashboard.

Os problemas de rastreamento são https://github.com/kubernetes/dashboard/issues/1671 e https://github.com/kubernetes/dashboard/issues/1504.

@ kubernetes / dashboard-keepers

Qual é o status / plano para TPR sem namespace? Não encontrei discussões sobre isso, talvez tenha perdido alguma coisa?

@sttts Para começar, estou intrigado com o desenvolvimento no Kubernetes. E quero contribuir com isso, mas Go é uma nova linguagem para mim. O que vocês me recomendam fazer para que eu consiga esse projeto para o GSoC 2017?

Para acrescentar algo sobre mim, sou bastante bom em C ++ e Java e sou bacharel em Ciência da Computação. Também comecei a ler a documentação e fiz o curso Udacity envolvendo Kubernetes.

@grpndrs , temos uma lista de problemas rotulados que são um bom ponto de partida para entrar no código: https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -contribuidores. Sinta-se à vontade para entrar em contato comigo no slack e podemos passar por alguns deles.

@enisoc

Multiple Resources, single version, different add times ainda é um problema? Posso criar e excluir vários TPRs sem problemas.

Além disso, podemos numerar as caixas de seleção em Outstanding Capabilities para que seja mais fácil consultá-las? @ deads2k eu acho que você pode fazer assim:

1. - [ ] ...
2. - [ ] ...

Alguém sabe como está indo o componente de validação disso? Eu trabalho muito com TPRs e esse recurso não teria preço e economizaria MUITO código personalizado. Eu adoraria contribuir com este recurso, mas gostaria de saber se alguém que se inscreveu neste problema conhece seu status

Alguém sabe como está indo o componente de validação disso?

Eu não espero que isso aconteça para 1.7. No momento, estamos discutindo alguns problemas estruturais de crescimento aqui https://github.com/kubernetes/community/pull/524 para fornecer uma base mais estável para crescer.

Eu não espero que isso aconteça para 1.7. No momento, estamos discutindo alguns problemas estruturais de crescimento aqui, kubernetes / community # 524, para fornecer uma base mais estável para o crescimento.

Planejamos avançar com https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md no prazo 1.7. Farei atualizações aqui e nas chamadas sig-apimachinery conforme avançamos.

@ deads2k Eu não vi nada lá sobre validação de tpr. Você não consideraria isso algo que seria necessário para o beta?

@frankgreco, a proposta é sobre uma base sólida para os TPRs se basearem. Recursos como validação podem ser adicionados posteriormente, mas estão fora do escopo aqui.

Eu editei o comentário pai deste tópico para usar o novo modelo e para esclarecer o escopo do trabalho planejado para 1.7, como eu o entendo. Por favor, olhe e corrija / comente.

@ deads2k @enisoc Recentemente, começamos a usar o TPR, e a validação do TPR será muito crítica para alguns de nossos próximos projetos. Se tivermos recursos para trabalhar nisso, você consideraria aceitar colaboradores da comunidade para que isso aconteça?

@ deads2k @enisoc Recentemente, começamos a usar o TPR, e a validação do TPR será muito crítica para alguns de nossos próximos projetos. Se tivermos recursos para trabalhar nisso, você consideraria aceitar colaboradores da comunidade para que isso aconteça?

Absolutamente. Para algo assim, queremos uma proposta de design antes de começarmos a examinar as solicitações pull. Além disso, dadas quantas abordagens diferentes são possíveis, eu sugiro que você liste as três ou mais ideias principais e dê uma breve explicação de por que aquela que você escolheu é a melhor. Por se tratar do lado do servidor, as considerações de desempenho e segurança são muito importantes.

Além disso, como esse é um recurso de longo alcance, é importante que não se torne uma contribuição imediata. Contribuições ativas (revisões, testes, código, migração) para a transição para https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md ajudariam. Estou deads2k em folga se você estiver interessado e quiser conversar.

Obrigado @ deads2k! Isso é totalmente razoável. Faremos algumas propostas de design para a validação do TPR, qual a melhor forma de compartilhá-lo? Eu vou afrouxar também

@ xiao-zhou, estamos felizes por ter um projeto do Google Summer of Code aceito em torno desse tópico (foi anunciado ontem). Vamos conversar no Slack sobre como colaborar nisso. Muito legal que você também esteja interessado nisso, então temos bastante força para levar isso adiante!

@ xiao-zhou @sttts @ deads2k assim que você tiver uma proposta para validação de TPR (e idealmente inadimplente), se importa em me marcar na revisão da proposta? Obrigado

@sdminonne será postado em sig-apimachinery. Se você se inscrever nesse grupo do Google, deverá ser notificado.

@sttts obrigado

@ deads2k, você vai adicionar ObservedGeneration para TPRs?

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@ deads2k, você vai adicionar ObservedGeneration para TPRs?

Eu não estava planejando. Um cliente que se preocupa não poderia simplesmente comparar nomes de especificações e status?

comparar nomes de especificações e status?

Não sei o que você quer dizer aqui. Corrija-me se eu estiver errado, mas acho que há duas partes relacionadas a ObservedGeneration: 1) o servidor API precisa atualizar metadata.generation toda vez que houver uma atualização nas especificações do TPR e 2) o controlador responsável pelo O TPR atualiza status.observedGeneration base em metadata.Generation . Acho que 1) é o que estou perguntando e 2) é algo que os autores do TPR precisam cuidar?

Não sei o que você quer dizer aqui. Corrija-me se eu estiver errado, mas acho que há duas partes relacionadas a ObservedGeneration: 1) o servidor API precisa atualizar metadata.generation toda vez que houver uma atualização nas especificações do TPR e 2) o controlador responsável pelo status de atualizações do TPR .observedGeneration com base em metadata.Generation. Acho que 1) é o que estou perguntando e 2) é algo que os autores do TPR precisam cuidar?

Oh, eu não entendi sobre o que você estava perguntando. Você desejaobservationGeneration para CustomResource, não CustomResourceDefinition. Achei que oobservationGeneration só recebeu alterações nas especificações que exigiam uma ação. O que significa que uma atualização de metadados não o acionou e uma atualização de alguns campos de especificação também pode evitar o choque.

No meu comentário com link acima, eu estava pedindo suporte à geração para instâncias de TPR, não para os próprios TPRs (embora isso também fosse bom. Algum motivo para não adicioná-lo a todos os objetos?).

Por exemplo, se eu tiver Kind: TPR; name: foo.example.com e uma instância desse TPR Kind: Foo; name: foo123 , estou interessado em Generation / ObservedGeneration para foo123 para que o controlador Foo possa informar aos consumidores Foo se foi processado uma atualização para a instância foo123 . Isso faz sentido? Não vejo como isso pode ser alcançado sem o suporte adequado no lado do servidor k8s.

Sim, generation / NoticeGeneration faz sentido para o esquema do usuário do TPR e não para o recurso TPR real conforme ele evoluiu.

@kargakis A regra é apenas incrementar a geração de objetos na atualização das especificações, não no status, certo? Nesse caso, significa que primeiro precisamos oferecer suporte oficialmente à divisão Spec / Status na instância TPR. Eu estava planejando escrever uma proposta para Status TPR, visando 1.8. Posso ter certeza de incluir o incremento da geração de objetos na proposta.

A regra é apenas incrementar a geração de objetos na atualização das especificações, não no status, certo?

Correto.

Nesse caso, significa que primeiro precisamos oferecer suporte oficialmente à divisão Spec / Status na instância TPR.

Sim, eu esperava encontrar essa divisão como parte do problema existente, mas parece que há mais trabalho a ser feito antes de chegarmos lá.

@kargakis Eu editei o comentário de nível superior para mencionar esses itens, embora eles estejam fora do escopo para 1.7.

/ cc

@ deads2k Devemos adicionar um nome curto para CustomResourceDefinition?

Adicionado shortname CRD para CustomResourceDefinition .

Uma proposta de design para validação de CustomResources: https://github.com/kubernetes/community/pull/708 : smile:

@ deads2k @enisoc @lavalamp
gostaria de saber se o usuário pode configurar métodos CURD AND (OR) do controlador k8s para objetos CRD

Em meu caso de uso específico, crio um networks.stable.example.com CRD e o utilizo para criar o objeto Rede net1:

Preciso garantir que um novo objeto Network CRD não possa ser criado se já existir um objeto Network CRD com um intervalo de sub-rede sobreposto

Se tal mecanismo não existir, terei o maior prazer em colocar algumas idéias juntas em um documento de design.

Conforme mencionado nas notas de lançamento e documentos do 1.7, o TPR agora está obsoleto e planejamos removê-lo no 1.8. Os usuários devem mudar para CRD durante o período de 1,7.

Comente sobre o problema de rastreamento para remoção se você tiver alguma dúvida ou preocupação.

Atualizações / planos para 1.8:

• Suporte a validação baseada em esquema JSON e padronização para CustomResources ( proposta )
• Adicione sub-recursos (como status e escala) para CRs (~ proposta será lançada em breve ~ proposta )

Obrigado @nikhita. Eu editei o comentário principal para refletir os planos 1.8.

A descoberta retorna informações corretas para CRs, mas o mapeador REST não as usa - https://github.com/kubernetes/kubernetes/issues/49948

Proposta de sub-recursos para recursos personalizados: https://github.com/kubernetes/community/pull/913 : tada:

Perdoe minha postagem incorreta, mas vim para esta página de outra página do kubernetes pensando que o kubernetes incluía uma estrutura de microsserviços, além de apenas gerenciar recursos de contêiner de terceiros.

O Redhat comercializa kubernetes OpenShift como uma plataforma de microsserviços, mas ainda não consigo encontrar esse recurso. Estou procurando um servidor de aplicativos como algo, para hospedar meu próprio conjunto de microsserviços de aplicativos independentes muito leves.

Isso existe ou estamos relegados a criar apps java gordo de guerra no springboot e implantá-los em um servidor tomcat que fica dentro de um contêiner gerenciado kuberenetes, que é difícil de gerenciar e implantar. Preciso de uma plataforma de microsserviços em que um administrador possa gerenciar e operar centenas de microsserviços.

Esta pergunta faz sentido?

@hectoralicea este repo é usado para planejar recursos trabalhados por desenvolvedores do Kubernetes.

Para perguntas gerais como esta, poste nos grupos de usuários do Kubernetes. Eles geralmente são muito mais úteis para esse tipo de discussão de alto nível :)

Consulte https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ ou Stack Overflow.

@colemickens @ deads2k @nikhita @enisoc Eu adicionei uma seção para 1.9.

@sttts Versão beta aprimorada na v1.9, certo?

Correções de bugs do

@sttts Eu estava pensando sobre a validação do CRD ... isso é abordado neste problema de recursos e passará para a versão beta na v1.9 ou?

@luxas da postagem inicial

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

Oh, obrigado @kargakis , não olhei lá: facepalm:: smile:

@ deads2k , @enisoc não há planos para "estabilidade" no 1.9, certo?

@idvoretskyi Certo.

@ deads2k : wave: Por favor, abra uma documentação PR e adicione um link para a planilha de rastreamento. Desde já, obrigado!

@ deads2k Por favor, abra uma documentação PR e adicione um link para a planilha de rastreamento. Desde já, obrigado!

@zacharysarah Parece que https://github.com/kubernetes/website/pull/6066

Para registro, o problema de versão do CRD existe aqui: https://github.com/kubernetes/features/issues/544.

Lista de tarefas para CRDs migrando para GA: https://github.com/kubernetes/kubernetes/issues/58682

@nikhita significa que todo o recurso CRD está mudando para GA?

isso significa que todo o recurso CRD está mudando para GA?

A API mudará para GA, ou seja, v1, possivelmente com alguns sub-recursos beta / alfa. Porém, ele não será encerrado quando isso acontecer, ou seja, se 1.10 é viável.

@sttts @nikhita você pode definir o roteiro de recursos com mais precisão?

você pode definir o roteiro do recurso com mais precisão?

Para 1,10:

• sub-recursos para recursos personalizados e correções de bugs (pelo menos aqueles não riscados) listados em https://github.com/kubernetes/kubernetes/issues/58682.

Não há um conjunto _exato_ de entregas planejadas para os próximos lançamentos, mas o plano é entrar em GA até o final do ano (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

Iremos para o GA assim que todos os problemas que não foram riscados em https://github.com/kubernetes/kubernetes/issues/58682 forem concluídos.

Quando a API CRD entra em GA, pode haver recursos nela (exemplo: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg / features / kube_features.go # L35) que podem estar em alfa / beta.

@sttts @nikhita @ deads2k
Algum plano para isso em 1.11?

Em caso afirmativo, certifique-se de que o recurso está atualizado com o apropriado:

• Descrição
• Marco
• Cessionário (s)
• Rótulos:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Algum plano para isso em 1.11?

Não tenho permissão para editar o corpo de RP (se alguém puder fazer isso, seria ótimo!). Mas o plano é:

• Implemente o controle de versão do CRD. Isso tem outro problema de recursos: https://github.com/kubernetes/features/issues/544. Proposta de design: https://github.com/kubernetes/community/pull/2026.
• Adicione poda e padronização para recursos customizados.
• Mapas de suporte no esquema de validação CRD. https://github.com/kubernetes/kubernetes/issues/59485
• Implementar suporte de cota para recursos personalizados (isso também pode ser considerado uma correção de bug) https://github.com/kubernetes/kubernetes/issues/53777

Em caso afirmativo, certifique-se de que o recurso está atualizado com o apropriado:
Descrição

A descrição de uma linha deve ser atualizada para incluir "Adicionar validação, padronização, sub-recursos e controle de

As propostas de design mencionadas na descrição devem incluir:

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

Alguém pode adicionar esses itens no corpo de relações públicas também?

Rótulos:

/ tipo recurso

/ cc @mbohlool

Alguém pode adicionar esses itens no corpo de relações públicas também?

feito

@nikhita @sttts @mbohlool - só para esclarecer, pretendemos beta para o ciclo 1.11?

@nikhita @sttts @mbohlool - pingando novamente nisso ...
Estamos almejando beta para 1.11? Só quero ter certeza de como é o congelamento de recursos hoje.

@justaugustus CRDs já são beta. GA não está planejado para 1.11.

Todos os recursos / extensões listados (remoção, padronização, controle de versão) provavelmente começarão como alfa.

@sttts Hmmm, nesse caso, devemos ter problemas separados para rastrear esses recursos / extensões e seus estágios de forma independente?

Para registrar - @nikhita criou um problema para o subfeature https://github.com/kubernetes/features/issues/571

@sttts @justaugustus

Problema de sub-recurso de padronização e remoção: https://github.com/kubernetes/features/issues/575

@justaugustus @idvoretskyi para fins de rastreamento do 1.12: haverá adições e talvez correções de bugs, mas permanecerá na versão beta do 1.12 (portanto, nenhuma mudança da perspectiva dos recursos).

Há um novo sub-recurso que está planejado como alfa, mas foi criado como um problema separado: https://github.com/kubernetes/features/issues/575.

Oi
Esse aprimoramento já foi rastreado antes, portanto, gostaríamos de verificar e ver se há algum plano de graduar estágios no Kubernetes 1.13. Esta versão é destinada a ser mais 'estável' e terá um cronograma agressivo. Inclua este aprimoramento apenas se houver um alto nível de confiança de que ele atenderá aos seguintes prazos:

• Docs (abrir espaço reservado para PRs): 11/8
• Código Slush: 11/9
• Início do congelamento de código: 15/11
• Documentos completos e revisados: 27/11

Por favor, reserve um momento para atualizar os marcos em sua postagem original para rastreamento futuro e ping @ kacole2 se precisar ser incluído na Folha de Rastreamento de Aprimoramentos 1.13

Obrigado!

Esse aprimoramento já foi rastreado antes, portanto, gostaríamos de verificar e ver se há algum plano de graduar estágios no Kubernetes 1.13.

Não, não há planos para graduar isso em 1.13. A API CRD permanecerá em beta.

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

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

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

/ remove-lifecycle stale

@ deads2k Olá - sou o líder do aprimoramento para 1.14 e estou verificando este problema para ver que trabalho (se houver) está sendo planejado para o lançamento 1.14. O congelamento de melhorias é 29 de janeiro e quero lembrar que todas as melhorias devem ter um KEP

@claurence A API CRD permanecerá em beta para 1.14 também.

Olá @nikhita @ deads2k , sou o líder de aprimoramento do 1.15. Este recurso estará graduando os estágios alfa / beta / estável no 1.15? Informe-nos para que possa ser rastreado corretamente e adicionado à planilha. Um KEP precisará ser mesclado para inclusão de 1,15 também. Obrigado!

Assim que a codificação começar, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente.

isso permanecerá em fase beta. o trabalho de validação, conversão e publicação OpenAPI acontecerá em 1.15

descrição atualizada com links para KEPs relevantes para 1.15

Ei, @liggitt @ deads2k @jpbetz @sttts Eu sou a sombra do lançamento de documentos v1.15.

Este aprimoramento (ou o trabalho planejado para a v1.15) requer novos documentos (ou modificações)?

Apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.15) com vencimento até quinta-feira, 30 de maio. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida! 😄

@ deads2k @jpbetz @sttts @liggitt

Apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.15) com vencimento até quinta-feira, 30 de maio. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida! 😄

Docs PR para 1.15: https://github.com/kubernetes/website/pull/14583

@ deads2k você pode atualizar a descrição do problema?

/ milestone v1.16
/ estágio estável

Ei, @liggitt @jpbetz @sttts , sou o líder de lançamento de documentos

Este aprimoramento (ou o trabalho planejado para v1.16) requer novos documentos (ou modificações)?

Apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.16) com vencimento até sexta-feira, 23 de agosto. Deixe-me saber se você tiver alguma dúvida!

@simonswine o espaço reservado PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts Quinta-feira é o congelamento do código. Há algum PRs k / k pendentes que impedirão que isso passe para Estável? Tudo na postagem original para o trabalho planejado 1.15 * parece ter sido mesclado.

Acredito que os PRs pendentes são apenas o aumento da versão do portal de recursos (https://github.com/kubernetes/kubernetes/pull/81965) e duas correções de bugs pendentes que devem acontecer nesta semana: https://github.com/kubernetes / kubernetes / pull / 81436 , https://github.com/kubernetes/kubernetes/issues/78707

documentos prontos para revisão em https://github.com/kubernetes/website/pull/15982

Lançado como estável na v1.16.0

Trabalho pós-GA rastreado em https://github.com/orgs/kubernetes/projects/28

/fechar

@liggitt : Fechando este problema.