Descrição do Recurso

• Descrição do recurso de uma linha (pode ser usada como uma nota de versão):
• Contato principal (cessionário):
• SIGs responsáveis:
• Link da proposta de design (repositório da comunidade): https://github.com/kubernetes/community/issues/429
• Revisor (es) - (para LGTM) recomendam que mais de 2 revisores (pelo menos um do arquivo OWNERS da área de código) concordem em revisar. Revisores de várias empresas preferidos:
• Aprovador (provavelmente do SIG / área à qual o recurso pertence):
• Meta de recurso (qual meta é igual a qual marco):
  
  
  
  • Alvo de liberação alfa (xy)
  
  
  • Meta de lançamento beta (xy)
  
  
  • Alvo de liberação estável (xy)
  
  

########## Modelo desatualizado abaixo

Descrição

IPvS ou LVS é um recurso do kernel que pode enviar solicitações de proxy de 3 maneiras diferentes. O modelo de roteamento direto é o modelo preferido.

Progress Tracker

• [] Alpha
  
  
  
  • [] Escrever e manter o rascunho do documento de qualidade
    
    
    
    
    
    • [] Durante o desenvolvimento, mantenha um documento atualizado sobre a experiência desejada com o recurso e como alguém pode experimentar o recurso em seu estado atual. Pense nisso como o README de seu novo recurso e um esqueleto para os documentos a serem escritos antes do lançamento do Kubernetes. Cole o link para o Documento Google: DOC-LINK
    
    
    
  
  
  • [] Aprovação de Projeto
    
    
    
    
    
    • [x] Proposta de Design. https://github.com/kubernetes/community/issues/429
    
    
    
    • [] Decida em qual repositório o código desse recurso será verificado. Nem tudo precisa chegar ao repositório principal do Kubernetes. REPO-NAME
    
    
    
    • [] Revisão inicial da API (se API). Talvez o mesmo PR do design doc. PR-NUMBER
    
    
    
    • Qualquer código que altera uma API ( /pkg/apis/... )
    
    
    
    • cc @kubernetes/api
    
    
    
    • [] Identifique o pastor (seu líder SIG e / ou [email protected] poderá ajudá-lo). Meu pastor é: _replace. [email protected]_ (e / ou GH Handle)
    
    
    
    • Um pastor é uma pessoa que ajudará a familiarizá-lo com o processo de colocar seu recurso no repositório, identificar revisores e fornecer feedback sobre o recurso. Eles _não_ (necessariamente) são o revisor de código do recurso ou o líder técnico da área.
    
    
    
    • O pastor _não_ é responsável por comparecer às reuniões do Kubernetes-PM e / ou comunicar se o recurso está no caminho certo para cumprir as metas de lançamento. Isso ainda é sua responsabilidade.
    
    
    
    • [] Identifique o ponto de contato secundário / backup. Meu ponto de contato secundário é: _replace. [email protected]_ (e / ou GH Handle)
    
    
    
  
  
  • [] Grave (código + testes + documentos) e depois mescle-os. TODOS OS NÚMEROS PR
    
    
    
    
    
    • [] O código precisa ser desabilitado por padrão. Verificado pelo código OWNERS
    
    
    
    • [] Teste mínimo
    
    
    
    • [] Documentos mínimos
    
    
    
    • cc @kubernetes/docs em docs PR
    
    
    
    • cc @kubernetes/feature-reviewers sobre este problema para obter aprovação antes de verificar isso
    
    
    
    • Nova apis: item da seção do glossário no repo docs: kubernetes / kubernetes.github.io
    
    
    
    • [] Atualizar notas de lançamento
    
    
    
  
  
• [] Beta
  
  
  
  • [] O teste é suficiente para beta
  
  
  • [] Documentos do usuário com tutoriais
    
    
    
    
    
    • Passo a passo / tutorial atualizado no repositório docs: kubernetes / kubernetes.github.io
    
    
    
    • cc @kubernetes/docs em docs PR
    
    
    
    • cc @kubernetes/feature-reviewers sobre este problema para obter aprovação antes de verificar isso
    
    
    
  
  
  • [] Revisão completa da API
  
  
  • cc @kubernetes/api
  
  
• [ ] Estábulo
  
  
  
  • [] docs / propostas / foo.md movido para docs / design / foo.md
    
    
    
    
    
    • cc @kubernetes/feature-reviewers sobre este problema para obter aprovação antes de verificar isso
    
    
    
  
  
  • [] Mergulhe, teste de carga
  
  
  • [] documentos e exemplos detalhados do usuário
  
  
  • cc @kubernetes/docs
  
  
  • cc @kubernetes/feature-reviewers sobre este problema para obter aprovação antes de verificar isso
  
  

FEATURE_STATUS é usado para rastreamento de recursos e deve ser atualizado por @kubernetes/feature-reviewers .
FEATURE_STATUS: IN_DEVELOPMENT

Mais conselhos:

Projeto

• Depois de obter o LGTM de um membro @kubernetes/feature-reviewers , você pode marcar esta caixa de seleção e o revisor aplicará o rótulo de "design completo".

Codificação

• Use quantos PRs você precisar. Escreva testes no mesmo PRs ou em diferentes, conforme for conveniente para você.
• À medida que cada PR é mesclado, adicione um comentário a esta questão fazendo referência aos PRs. O código vai para o repositório http://github.com/kubernetes/kubernetes ,
  e às vezes http://github.com/kubernetes/contrib ou outros repositórios.
• Quando terminar de usar o código, aplique o rótulo "código completo".
• Quando o recurso tiver documentos do usuário, adicione um comentário mencionando @kubernetes/feature-reviewers e eles irão
  verifique se o código corresponde ao recurso e design propostos, e se tudo está feito, e se há
  teste. Eles não farão revisão de código detalhada: isso já aconteceu quando seus PRs foram revisados.
  Quando isso for feito, você pode marcar esta caixa e o revisor aplicará o rótulo "código completo".

Docs

• [] Escreva documentos de usuário e faça com que sejam mesclados.
• Os documentos do usuário vão para http://github.com/kubernetes/kubernetes.github.io.
• Quando o recurso tiver documentos do usuário, adicione um comentário mencionando @kubernetes/docs .
• Ao obter o LGTM, você pode marcar esta caixa de seleção e o revisor aplicará o rótulo "docs-complete".