Default Namespace labels #26994
Closed
Default Namespace labels #26994
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is to update operator web page to list operator tools in alphabetical order as well as other minor improvements.
Signed-off-by: ishii1648 <[email protected]>
The `imagePullPolicy` field is set automatically based on the image tag if it's initially omitted, but it is not updated if the image tag later changes. This can lead to [confusing behaviour](https://itnext.io/defaults-are-hard-kubernetes-deployment-edition-3b11095792f2). This change attempts to warn users of this potential pitfall.
Fix typos Update the file according to devlware's suggestion
Signed-off-by: timyinshi <[email protected]>
/docs/reference/setup-tools/kubeadm/kubeadm/ is redirected to /docs/reference/setup-tools/kubeadm/ This replaces the redirect links of kubeadm with the direct links.
modify the error chinese word
* Add Dont Panic blog post in pt language Add Dont Panic blog post in pt language. Partial fix for kubernetes kubernetes#13939 * Update content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: Tim Bannister <[email protected]> * Update content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: Tim Bannister <[email protected]> * Update 2020-12-02-dont-panic-kubernetes-and-docker.md typo `:%s/\<kubernetes\>/Kubernetes/gc` and `:%s/é/e` * Update 2020-12-02-dont-panic-kubernetes-and-docker.md removendo depreciação e arrumando typos * remove enterprise name * Update content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: Tim Bannister <[email protected]> Update content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: Tim Bannister <[email protected]> Update 2020-12-02-dont-panic-kubernetes-and-docker.md typo `:%s/\<kubernetes\>/Kubernetes/gc` and `:%s/é/e` Update 2020-12-02-dont-panic-kubernetes-and-docker.md removendo depreciação e arrumando typos remove enterprise name Co-authored-by: Tim Bannister <[email protected]>
updating docsy theme submodule
* Sync with english version in 'chore: fix an invalid location.hash (kubernetes#26835)' Signed-off-by: ydFu <[email protected]>
…ificates [zh] translate task certificates
The Categories field for CRDs was documented as beta in 1.10 in kubernetes#7439 mainly because CRDs were in beta back then. The `feature-state` tag for this section was added in kubernetes#2754, however this section doesn't need a `feature-state` tag because the field is not gated by any feature gate: https://github.com/kubernetes/kubernetes/blob/90851a0fb5bbb6f02b3c22715f9f91609f8ee438/staging/src/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1/types.go#L247-L251 It is now safe to remove the feature-state tag. Moreover, CRDs are now GA so the beta state is not accurate.
femrtnz's suggestion Co-authored-by: Felipe <[email protected]>
fixed typo at line 50
Co-authored-by: Diego W. Antunes <[email protected]>
Co-authored-by: Diego W. Antunes <[email protected]>
Co-authored-by: Diego W. Antunes <[email protected]>
Add concepts/containers/images.md in pt language
in content/en/docs/setup/production-environment/container-runtimes.md
Fix typo (form -> from)
in content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
[ja] fix an invalid url
…or-services-with-type-loadbalancer Fix the translation about Source IP for Services with Type=LoadBalancer
…t language (kubernetes#26710) * Add Concepts/Overview for Kubernetes and Components, and glossary itens in pt Modify Glossary/Control-Plane definition in pt Changes to be committed: new file: content/pt/docs/concepts/overview/_index.md new file: content/pt/docs/concepts/overview/components.md new file: content/pt/docs/concepts/overview/what-is-kubernetes.md new file: content/pt/docs/reference/glossary/cloud-controller-manager.md new file: content/pt/docs/reference/glossary/cncf.md new file: content/pt/docs/reference/glossary/container-runtime.md modified: content/pt/docs/reference/glossary/control-plane.md new file: content/pt/docs/reference/glossary/etcd.md new file: content/pt/docs/reference/glossary/kube-apiserver.md new file: content/pt/docs/reference/glossary/kube-controller-manager.md new file: content/pt/docs/reference/glossary/kube-proxy.md new file: content/pt/docs/reference/glossary/kube-scheduler.md modified: package-lock.json * Changes to be committed: modified: package-lock.json Untracked files: content/pt/docs/concepts/overview/kubernetes-api.md * Changes to be committed: modified: package-lock.json Untracked files: content/pt/docs/concepts/overview/kubernetes-api.md * --- reviewers: - lavalamp - rikatz title: Componentes do Kubernetes content_type: concept description: > Um cluster Kubernetes consiste de componentes que representam a camada de gerenciamento, e um conjunto de máquinas chamadas nós. weight: 20 card: name: concepts weight: 20 --- <!-- overview --> Ao implantar o Kubernetes, você obtém um cluster. {{< glossary_definition term_id="cluster" length="all" prepend="Um cluster Kubernetes consiste em">}} Este documento descreve os vários componentes que você precisa ter para implantar um cluster Kubernetes completo e funcional. Esse é o diagrama de um cluster Kubernetes com todos os componentes interligados.  <!-- body --> ## Componentes da camada de gerenciamento Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster (por exemplo, agendamento de _pods_), bem como detectam e respondem aos eventos do cluster (por exemplo, iniciando um novo _{{< glossary_tooltip text="pod" term_id="pod" >}}_ quando o campo `replicas` de um _Deployment_ não está atendido). Os componentes da camada de gerenciamento podem ser executados em qualquer máquina do cluster. Contudo, para simplificar, os _scripts_ de configuração normalmente iniciam todos os componentes da camada de gerenciamento na mesma máquina, e não executa contêineres de usuário nesta máquina. Veja [Construindo clusters de alta disponibilidade](/docs/admin/high-availability/) para um exemplo de configuração de múltiplas VMs para camada de gerenciamento (_multi-main-VM_). ### kube-apiserver {{< glossary_definition term_id="kube-apiserver" length="all" >}} ### etcd {{< glossary_definition term_id="etcd" length="all" >}} ### kube-scheduler {{< glossary_definition term_id="kube-scheduler" length="all" >}} ### kube-controller-manager {{< glossary_definition term_id="kube-controller-manager" length="all" >}} Alguns tipos desses controladores são: * Controlador de nó: responsável por perceber e responder quando os nós caem. * Controlador de _Job_: Observa os objetos _Job_ que representam tarefas únicas e, em seguida, cria _pods_ para executar essas tarefas até a conclusão. * Controlador de _endpoints_: preenche o objeto _Endpoints_ (ou seja, junta os Serviços e os _pods_). * Controladores de conta de serviço e de _token_: crie contas padrão e _tokens_ de acesso de API para novos _namespaces_. ### cloud-controller-manager {{< glossary_definition term_id="cloud-controller-manager" length="short" >}} O cloud-controller-manager executa apenas controladores que são específicos para seu provedor de nuvem. Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu próprio PC, o cluster não possui um gerenciador de controlador de nuvem. Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (exectuar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas. Os seguintes controladores podem ter dependências de provedor de nuvem: * Controlador de nó: para verificar junto ao provedor de nuvem para determinar se um nó foi excluído da nuvem após parar de responder. * Controlador de rota: para configurar rotas na infraestrutura de nuvem subjacente. * Controlador de serviço: Para criar, atualizar e excluir balanceadores de carga do provedor de nuvem. ## Node Components Os componentes de nó são executados em todos os nós, mantendo os _pods_ em execução e fornecendo o ambiente de execução do Kubernetes. ### kubelet {{< glossary_definition term_id="kubelet" length="all" >}} ### kube-proxy {{< glossary_definition term_id="kube-proxy" length="all" >}} ### Container runtime {{< glossary_definition term_id="container-runtime" length="all" >}} ## Addons Complementos (_addons_) usam recursos do Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) para implementar funcionalidades do cluster. Como fornecem funcionalidades em nível do cluster, recursos de _addons_ que necessitem ser criados dentro de um _namespace_ pertencem ao _namespace_ `kube-system`. Alguns _addons_ selecionados são descritos abaixo; para uma lista estendida dos _addons_ disponíveis, por favor consulte [Addons](/docs/concepts/cluster-administration/addons/). ### DNS Embora os outros complementos não sejam estritamente necessários, todos os clusters do Kubernetes devem ter um [DNS do cluster](/docs/concepts/services-networking/dns-pod-service/), já que muitos exemplos dependem disso. O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes. Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS. ### Web UI (Dashboard) [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma interface de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicações em execução no cluster, bem como o próprio cluster. ### Monitoramento de recursos do contêiner [Monitoramento de recursos do contêiner](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) registra métricas de série temporal genéricas sobre os contêineres em um banco de dados central e fornece uma interface de usuário para navegar por esses dados. ### Logging a nivel do cluster Um mecanismo de [_logging_ a nível do cluster](/docs/concepts/cluster-administration/logging/) é responsável por guardar os _logs_ dos contêineres em um armazenamento central de _logs_ com um interface para navegação/pesquisa. ## {{% heading "whatsnext" %}} * Aprenda sobre [Nós](/docs/concepts/architecture/nodes/). * Aprenda sobre [Controladores](/docs/concepts/architecture/controller/). * Aprenda sobre [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/). * Leia a [documentação](https://etcd.io/docs/) oficial do **etcd**. * --- reviewers: title: Componentes do Kubernetes content_type: concept description: > Um cluster Kubernetes consiste de componentes que representam a camada de gerenciamento, e um conjunto de máquinas chamadas nós. weight: 20 card: name: concepts weight: 20 --- <!-- overview --> Ao implantar o Kubernetes, você obtém um cluster. {{< glossary_definition term_id="cluster" length="all" prepend="Um cluster Kubernetes consiste em">}} Este documento descreve os vários componentes que você precisa ter para implantar um cluster Kubernetes completo e funcional. Esse é o diagrama de um cluster Kubernetes com todos os componentes interligados.  <!-- body --> ## Componentes da camada de gerenciamento Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster (por exemplo, agendamento de _pods_), bem como detectam e respondem aos eventos do cluster (por exemplo, iniciando um novo _{{< glossary_tooltip text="pod" term_id="pod" >}}_ quando o campo `replicas` de um _Deployment_ não está atendido). Os componentes da camada de gerenciamento podem ser executados em qualquer máquina do cluster. Contudo, para simplificar, os _scripts_ de configuração normalmente iniciam todos os componentes da camada de gerenciamento na mesma máquina, e não executa contêineres de usuário nesta máquina. Veja [Construindo clusters de alta disponibilidade](/docs/admin/high-availability/) para um exemplo de configuração de múltiplas VMs para camada de gerenciamento (_multi-main-VM_). ### kube-apiserver {{< glossary_definition term_id="kube-apiserver" length="all" >}} ### etcd {{< glossary_definition term_id="etcd" length="all" >}} ### kube-scheduler {{< glossary_definition term_id="kube-scheduler" length="all" >}} ### kube-controller-manager {{< glossary_definition term_id="kube-controller-manager" length="all" >}} Alguns tipos desses controladores são: * Controlador de nó: responsável por perceber e responder quando os nós caem. * Controlador de _Job_: Observa os objetos _Job_ que representam tarefas únicas e, em seguida, cria _pods_ para executar essas tarefas até a conclusão. * Controlador de _endpoints_: preenche o objeto _Endpoints_ (ou seja, junta os Serviços e os _pods_). * Controladores de conta de serviço e de _token_: crie contas padrão e _tokens_ de acesso de API para novos _namespaces_. ### cloud-controller-manager {{< glossary_definition term_id="cloud-controller-manager" length="short" >}} O cloud-controller-manager executa apenas controladores que são específicos para seu provedor de nuvem. Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu próprio PC, o cluster não possui um gerenciador de controlador de nuvem. Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (exectuar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas. Os seguintes controladores podem ter dependências de provedor de nuvem: * Controlador de nó: para verificar junto ao provedor de nuvem para determinar se um nó foi excluído da nuvem após parar de responder. * Controlador de rota: para configurar rotas na infraestrutura de nuvem subjacente. * Controlador de serviço: Para criar, atualizar e excluir balanceadores de carga do provedor de nuvem. ## Node Components Os componentes de nó são executados em todos os nós, mantendo os _pods_ em execução e fornecendo o ambiente de execução do Kubernetes. ### kubelet {{< glossary_definition term_id="kubelet" length="all" >}} ### kube-proxy {{< glossary_definition term_id="kube-proxy" length="all" >}} ### Container runtime {{< glossary_definition term_id="container-runtime" length="all" >}} ## Addons Complementos (_addons_) usam recursos do Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) para implementar funcionalidades do cluster. Como fornecem funcionalidades em nível do cluster, recursos de _addons_ que necessitem ser criados dentro de um _namespace_ pertencem ao _namespace_ `kube-system`. Alguns _addons_ selecionados são descritos abaixo; para uma lista estendida dos _addons_ disponíveis, por favor consulte [Addons](/docs/concepts/cluster-administration/addons/). ### DNS Embora os outros complementos não sejam estritamente necessários, todos os clusters do Kubernetes devem ter um [DNS do cluster](/docs/concepts/services-networking/dns-pod-service/), já que muitos exemplos dependem disso. O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes. Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS. ### Web UI (Dashboard) [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma interface de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicações em execução no cluster, bem como o próprio cluster. ### Monitoramento de recursos do contêiner [Monitoramento de recursos do contêiner](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) registra métricas de série temporal genéricas sobre os contêineres em um banco de dados central e fornece uma interface de usuário para navegar por esses dados. ### Logging a nivel do cluster Um mecanismo de [_logging_ a nível do cluster](/docs/concepts/cluster-administration/logging/) é responsável por guardar os _logs_ dos contêineres em um armazenamento central de _logs_ com um interface para navegação/pesquisa. ## {{% heading "whatsnext" %}} * Aprenda sobre [Nós](/docs/concepts/architecture/nodes/). * Aprenda sobre [Controladores](/docs/concepts/architecture/controller/). * Aprenda sobre [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/). * Leia a [documentação](https://etcd.io/docs/) oficial do **etcd**. * --- reviewers: title: O que é Kubernetes? description: > Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis. content_type: concept weight: 10 card: name: concepts weight: 10 sitemap: priority: 0.9 --- <!-- overview --> Essa página é uma visão geral do Kubernetes. <!-- body --> Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis. O Google tornou Kubernetes um projeto de código-aberto em 2014. O Kubernetes combina [mais de 15 anos de experiência do Google](/blog/2015/04/borg-predecessor-to-kubernetes/) executando cargas de trabalho produtivas em escala, com as melhores idéias e práticas da comunidade. O nome **Kubernetes** tem origem no Grego, significando _timoneiro_ ou _piloto_. **K8s** é a abreviação derivada pela troca das oito letras "ubernete" por "8", se tornado _K"8"s_. ## Voltando no tempo Vamos dar uma olhada no porque o Kubernetes é tão útil, voltando no tempo.  **Era da implantação tradicional:** No início, as organizações executavam aplicações em servidores físicos. Não havia como definir limites de recursos para aplicações em um mesmo servidor físico, e isso causava problemas de alocação de recursos. Por exemplo, se várias aplicações fossem executadas em um mesmo servidor físico, poderia haver situações em que uma aplicação ocupasse a maior parte dos recursos e, como resultado, o desempenho das outras aplicações seria inferior. Uma solução para isso seria executar cada aplicação em um servidor físico diferente. Mas isso não escalava, pois os recursos eram subutilizados, e se tornava custoso para as organizações manter muitos servidores físicos. **Era da implantação virtualizada:** Como solução, a virtualização foi introduzida. Esse modelo permite que você execute várias máquinas virtuais (VMs) em uma única CPU de um servidor físico. A virtualização permite que as aplicações sejam isoladas entre as VMs, e ainda fornece um nível de segurança, pois as informações de uma aplicação não podem ser acessadas livremente por outras aplicações. A virtualização permite melhor utilização de recursos em um servidor físico, e permite melhor escalabilidade porque uma aplicação pode ser adicionada ou atualizada facilmente, reduz os custos de hardware e muito mais. Com a virtualização, você pode apresentar um conjunto de recursos físicos como um cluster de máquinas virtuais descartáveis. Cada VM é uma máquina completa que executa todos os componentes, incluindo seu próprio sistema operacional, além do hardware virtualizado. **Era da implantação em contêineres:** Contêineres são semelhantes às VMs, mas têm propriedades de isolamento flexibilizados para compartilhar o sistema operacional (SO) entre as aplicações. Portanto, os contêineres são considerados leves. Semelhante a uma VM, um contêiner tem seu próprio sistema de arquivos, compartilhamento de CPU, memória, espaço de processo e muito mais. Como eles estão separados da infraestrutura subjacente, eles são portáveis entre nuvens e distribuições de sistema operacional. Contêineres se tornaram populares porque eles fornecem benefícios extra, tais como: * Criação e implantação ágil de aplicações: aumento da facilidade e eficiência na criação de imagem de contêiner comparado ao uso de imagem de VM. * Desenvolvimento, integração e implantação contínuos: fornece capacidade de criação e de implantação de imagens de contêiner de forma confiável e frequente, com a funcionalidade de efetuar reversões rápidas e eficientes (devido à imutabilidade da imagem). * Separação de interesses entre Desenvolvimento e Operações: crie imagens de contêineres de aplicações no momento de construção/liberação em vez de no momento de implantação, desacoplando as aplicações da infraestrutura. * A capacidade de observação (Observabilidade) não apenas apresenta informações e métricas no nível do sistema operacional, mas também a integridade da aplicação e outros sinais. * Consistência ambiental entre desenvolvimento, teste e produção: funciona da mesma forma em um laptop e na nuvem. * Portabilidade de distribuição de nuvem e sistema operacional: executa no Ubuntu, RHEL, CoreOS, localmente, nas principais nuvens públicas e em qualquer outro lugar. * Gerenciamento centrado em aplicações: eleva o nível de abstração da execução em um sistema operacional em hardware virtualizado à execução de uma aplicação em um sistema operacional usando recursos lógicos. * Microserviços fracamente acoplados, distribuídos, elásticos e livres: as aplicações são divididas em partes menores e independentes e podem ser implantados e gerenciados dinamicamente - não uma pilha monolítica em execução em uma grande máquina de propósito único. * Isolamento de recursos: desempenho previsível de aplicações. * Utilização de recursos: alta eficiência e densidade. ## Por que você precisa do Kubernetes e o que ele pode fazer{#why-you-need-kubernetes-and-what-can-it-do} Os contêineres são uma boa maneira de agrupar e executar suas aplicações. Em um ambiente de produção, você precisa gerenciar os contêineres que executam as aplicações e garantir que não haja tempo de inatividade. Por exemplo, se um contêiner cair, outro contêiner precisa ser iniciado. Não seria mais fácil se esse comportamento fosse controlado por um sistema? É assim que o Kubernetes vem ao resgate! O Kubernetes oferece uma estrutura para executar sistemas distribuídos de forma resiliente. Ele cuida do escalonamento e do recuperação à falha de sua aplicação, fornece padrões de implantação e muito mais. Por exemplo, o Kubernetes pode gerenciar facilmente uma implantação no método canário para seu sistema. O Kubernetes oferece a você: * **Descoberta de serviço e balanceamento de carga** O Kubernetes pode expor um contêiner usando o nome DNS ou seu próprio endereço IP. Se o tráfego para um contêiner for alto, o Kubernetes pode balancear a carga e distribuir o tráfego de rede para que a implantação seja estável. * **Orquestração de armazenamento** O Kubernetes permite que você monte automaticamente um sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem pública e muito mais. * **Lançamentos e reversões automatizadas** Você pode descrever o estado desejado para seus contêineres implantados usando o Kubernetes, e ele pode alterar o estado real para o estado desejado em um ritmo controlada. Por exemplo, você pode automatizar o Kubernetes para criar novos contêineres para sua implantação, remover os contêineres existentes e adotar todos os seus recursos para o novo contêiner. * **Empacotamento binário automático** Você fornece ao Kubernetes um cluster de nós que pode ser usado para executar tarefas nos contêineres. Você informa ao Kubernetes de quanta CPU e memória (RAM) cada contêiner precisa. O Kubernetes pode encaixar contêineres em seus nós para fazer o melhor uso de seus recursos. * **Autocorreção** O Kubernetes reinicia os contêineres que falham, substitui os contêineres, elimina os contêineres que não respondem à verificação de integridade definida pelo usuário e não os anuncia aos clientes até que estejam prontos para servir. * **Gerenciamento de configuração e de segredos** O Kubernetes permite armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves SSH. Você pode implantar e atualizar segredos e configuração de aplicações sem reconstruir suas imagens de contêiner e sem expor segredos em sua pilha de configuração. ## O que o Kubernetes não é O Kubernetes não é um sistema PaaS (plataforma como serviço) tradicional e completo. Como o Kubernetes opera no nível do contêiner, e não no nível do hardware, ele fornece alguns recursos geralmente aplicáveis comuns às ofertas de PaaS, como implantação, escalonamento, balanceamento de carga, e permite que os usuários integrem suas soluções de _logging_, monitoramento e alerta. No entanto, o Kubernetes não é monolítico, e essas soluções padrão são opcionais e conectáveis. O Kubernetes fornece os blocos de construção para a construção de plataformas de desenvolvimento, mas preserva a escolha e flexibilidade do usuário onde é importante. Kubernetes: * Não limita os tipos de aplicações suportadas. O Kubernetes visa oferecer suporte a uma variedade extremamente diversa de cargas de trabalho, incluindo cargas de trabalho sem estado, com estado e de processamento de dados. Se uma aplicação puder ser executada em um contêiner, ele deve ser executado perfeitamente no Kubernetes. * Não implanta código-fonte e não constrói sua aplicação. Os fluxos de trabalho de integração contínua, entrega e implantação (CI/CD) são determinados pelas culturas e preferências da organização, bem como pelos requisitos técnicos. * Não fornece serviços em nível de aplicação, tais como middleware (por exemplo, barramentos de mensagem), estruturas de processamento de dados (por exemplo, Spark), bancos de dados (por exemplo, MySQL), caches, nem sistemas de armazenamento em cluster (por exemplo, Ceph), como serviços integrados. Esses componentes podem ser executados no Kubernetes e/ou podem ser acessados por aplicações executadas no Kubernetes por meio de mecanismos portáteis, como o [Open Service Broker](https://openservicebrokerapi.org/). * Não dita soluções de _logging_, monitoramento ou alerta. Ele fornece algumas integrações como prova de conceito e mecanismos para coletar e exportar métricas. * Não fornece nem exige um sistema/idioma de configuração (por exemplo, Jsonnet). Ele fornece uma API declarativa que pode ser direcionada por formas arbitrárias de especificações declarativas. * Não fornece nem adota sistemas abrangentes de configuração de máquinas, manutenção, gerenciamento ou autocorreção. * Adicionalmente, o Kubernetes não é um mero sistema de orquestração. Na verdade, ele elimina a necessidade de orquestração. A definição técnica de orquestração é a execução de um fluxo de trabalho definido: primeiro faça A, depois B e depois C. Em contraste, o Kubernetes compreende um conjunto de processos de controle independentes e combináveis que conduzem continuamente o estado atual em direção ao estado desejado fornecido. Não importa como você vai de A para C. O controle centralizado também não é necessário. Isso resulta em um sistema que é mais fácil de usar e mais poderoso, robusto, resiliente e extensível. ## {{% heading "whatsnext" %}} * Dê uma olhada em [Componentes do Kubernetes](/docs/concepts/overview/components/). * Pronto para [Iniciar](/docs/setup/)?
delete some dirty code from several files in ja
remove images from dashboard blog page
Replace redirect links of kubeadm
Update operator page to list tools in alphabetical order
feat: add print directive allows print sections.
This simplifies the containerd installation instructions. All Linux distros will now download from Docker repos, including Ubuntu 18.04 which previously installed from Ubuntu repos. The Docker runtime instructions have also been simplified. The RHEL/CentOS specific option overlay2.override_kernel_check=true option has been removed. It seems Docker will now autodetect overlay2 support on older Linux kernels <4.0.0,>=3.10.0-514, which have back-ported overlay2 support on RHEL/CentOS 7.4+ See moby/moby#34368
…up-install-steps Update Ubuntu/Debian installation instructions to use Signed-By option
|
Deploy preview for kubernetes-io-vnext-staging processing. Building with commit 0a4be94 https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/60490a8a6166c90008d84696 |
k8s-ci-robot
added
the
area/blog
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
language/en
|
ouch....dirty branch... |
k8s-ci-robot
added
language/ja
k8s-ci-robot
added
the
cncf-cla: yes
rikatz
force-pushed
the
namespace-by-name
branch
from
0a4be94
to
482df7b
Compare
|
wrong branch wrong branch you made me so sad... Opening a new PR with everything corrected ;P |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the docs for the default namespace labels, created by Kep kubernetes/enhancements#2161