«Qual é a diferença entre Kubernetes e OpenShift?» – essa pergunta surge com uma frequência impressionante. Na verdade, é como perguntar qual a diferença entre um carro e um motor. Se continuarmos a analogia, o carro é o produto final, pronto para uso imediato: você entra e sai. Por outro lado, para que o motor o leve a algum lugar, ele precisa ser complementado com uma série de outros componentes para, no final, se tornar o carro.
Portanto, Kubernetes é esse motor em torno do qual o carro (plataforma) chamado OpenShift é construído, que o leva ao seu destino.
Neste artigo, queremos lembrar e detalhar um pouco mais os seguintes pontos-chave:
- Kubernetes é o coração da plataforma OpenShift. E é um Kubernetes 100% certificado, com código totalmente aberto e sem a menor propriedade restrita. Resumindo:
- A API para o cluster OpenShift é 100% Kubernetes.
- Se um contêiner funciona em qualquer outro sistema Kubernetes, ele funcionará sem modificações no OpenShift. Não é necessário fazer alterações nos aplicativos.
- OpenShift não apenas complementa o Kubernetes com recursos e funcionalidades úteis. Assim como um carro, o OpenShift está imediatamente pronto para uso, pode ser colocado em produção de imediato e, como mostraremos a seguir, simplifica significativamente a vida do desenvolvedor. Por isso, o OpenShift é único em dois aspectos. É uma plataforma PaaS corporativa de grande sucesso e bem conhecida do ponto de vista do desenvolvedor. E, ao mesmo tempo, é uma solução extremamente confiável da classe Container-as-a-Service do ponto de vista de operações industriais.
OpenShift é Kubernetes com 100% de certificação da CNCF.
Na base do OpenShift está Portanto, após o treinamento adequado, os usuários se surpreendem com o poder do kubectl. E aqueles que migraram do Kubernetes para o OpenShift frequentemente comentam como gostam de que, após redirecionar o kubeconfig para o cluster OpenShift, todos os scripts existentes funcionam perfeitamente.
Você provavelmente já ouviu falar da ferramenta de linha de comando do OpenShift chamada OC. Ela é totalmente compatível em comandos com o kubectl, além de oferecer alguns utilitários úteis que serão úteis em uma série de tarefas. Mas primeiro, um pouco mais sobre a compatibilidade entre OC e kubectl:
Comandos kubectl
Comandos OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Veja como são os resultados do uso do kubectl na API do OpenShift:
• kubectl get pods – retorna, como esperado, os pods.
• kubectl get namespaces – retorna, como esperado, os namespaces.
O comando kubectl create -f mydeployment.yaml cria recursos Kubernetes exatamente como em qualquer outra plataforma Kubernetes, conforme mostrado no vídeo abaixo:
Em outras palavras, todas as APIs do Kubernetes estão completamente disponíveis no OpenShift, mantendo 100% de compatibilidade. É por isso que .
O OpenShift complementa o Kubernetes com funcionalidades úteis.
As APIs do Kubernetes estão 100% disponíveis no OpenShift, mas a ferramenta padrão do Kubernetes, kubectl, claramente precisa de mais funcionalidades e conveniência. Por isso, a Red Hat adicionou recursos úteis e ferramentas de linha de comando ao Kubernetes, como OC (abreviação de OpenShift client) e ODO (OpenShift DO, que é projetado para desenvolvedores).
1. A ferramenta OC – uma versão mais poderosa e conveniente do Kubectl.
Por exemplo, ao contrário do kubectl, ela permite criar novos namespaces e mudar de contexto facilmente, além de oferecer uma série de comandos úteis para desenvolvedores, como para construir imagens de contêiner e implantar aplicativos diretamente do código-fonte ou de arquivos binários (Source-to-image, s2i).
Vamos ver, através de exemplos, como os helpers integrados e as funcionalidades expandidas da ferramenta OC ajudam a simplificar o trabalho cotidiano.
Exemplo um – gerenciamento de namespaces. Em cada cluster Kubernetes, sempre há vários namespaces. Normalmente, eles são usados para criar ambientes de desenvolvimento e produção, mas também podem ser usados, por exemplo, para fornecer a cada desenvolvedor um "sandbox" pessoal. Na prática, isso leva o desenvolvedor a constantemente alternar entre namespaces, uma vez que o kubectl trabalha no contexto do namespace atual. Portanto, no caso do kubectl, as pessoas costumam usar scripts helper para isso. Com o uso do OC, para mudar para o namespace desejado, basta digitar “oc project namespace”.
Você não se lembra como se chama o namespace que precisa? Sem problema, é só digitar "oc get projects" para exibir a lista completa. Está cético sobre como isso funcionará se você tiver acesso a apenas um subconjunto limitado de namespaces no cluster? Bem, porque o kubectl faz isso corretamente somente se o RBAC permitir que você veja todos os namespaces no cluster, e em grandes clusters, essas permissões não são concedidas a todos. Portanto, a resposta é: para o OC isso não é problema e ele facilmente fornecerá a lista completa nessa situação. É desses pequenos detalhes que se forma a orientação corporativa do Openshift e a boa escalabilidade dessa plataforma em termos de usuários e aplicações.
2. ODO – uma versão aprimorada do kubectl para desenvolvedores.
Como mais um exemplo das melhorias do Red Hat OpenShift em relação ao Kubernetes, podemos mencionar a ferramenta de linha de comando ODO. Ela é destinada a desenvolvedores e permite implantar rapidamente o código local em um cluster remoto do OpenShift. Além disso, com ela é possível otimizar os processos internos para sincronizar instantaneamente todas as alterações de código com os contêineres no cluster remoto do OpenShift, sem a necessidade de reconstruir, fazer o upload no registro e implantar novamente as imagens.
Vamos ver como o OC e o ODO facilitam o trabalho com contêineres e Kubernetes.
Vamos comparar alguns fluxos de trabalho quando são construídos com base no kubectl e quando são aplicados OC ou ODO.
• Implantação de código no OpenShift para quem não domina o idioma YAML:
Kubernetes / kubectl
$> git clone
1- Criamos um Dockerfile que constrói a imagem a partir do código.
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Construímos a imagem.
$> podman build …
3- Fazemos login no registro.
podman login …
4- Enviamos a imagem para o registro.
podman push
5- Criamos arquivos yaml para implantar a aplicação (deployment.yaml, service.yaml, ingress.yaml) – esse é o mínimo absoluto.
6- Implantamos os arquivos de manifesto:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – nome_da_nossa_aplicação
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Alteração de contexto: mudança de namespace ou cluster de trabalho.
Kubernetes / kubectl
1- Criamos um contexto no kubeconfig para o projeto "myproject".
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Controle de qualidade: "Aqui apareceu uma função interessante, ainda na versão alfa. Será que a vamos colocar em produção?"
Imagine que você é colocado em um carro de corrida e dizem: "Instalamos freios de um novo tipo e, honestamente, ainda não estão totalmente confiáveis... Mas não se preocupe, estaremos melhorando-os ativamente durante o campeonato." O que você acha dessa perspectiva? Para nós, da Red Hat, não é muito encorajadora. 🙂
Portanto, tentamos evitar versões alfa até que estejam suficientemente maduras, e realizemos testes rigorosos em um ambiente real e sintamos que podem ser usadas com segurança. Normalmente, tudo passa primeiro pela fase Dev Preview, depois pela e só então é lançado como uma versão pública. (GA), que é estável o suficiente para ser usado em produção.
Por que é assim? Porque, assim como no desenvolvimento de qualquer outro software, nem todas as ideias iniciais no Kubernetes chegam à versão final. Ou chegam, e até preservam a funcionalidade planejada, mas sua implementação difere radicalmente daquela que estava na versão alfa. Como milhares e milhares de clientes da Red Hat usam o OpenShift para suportar tarefas críticas, colocamos uma ênfase especial na estabilidade de nossa plataforma e no suporte de longo prazo.
A Red Hat lança de forma intencional atualizações frequentes do OpenShift e atualiza a versão do Kubernetes que faz parte dele. Por exemplo, na GA do OpenShift 4.3, que estamos escrevendo este artigo, está embutida a versão 1.16 do Kubernetes, que está apenas uma versão atrás da versão upstream do Kubernetes, número 1.17. Assim, tentamos fornecer ao cliente um Kubernetes de classe enterprise e garantir controle de qualidade adicional no processo de lançamento de novas versões do OpenShift.
Correções de software: "Naquela versão do Kubernetes que está em produção, encontramos uma vulnerabilidade. E só pode ser fechada com uma atualização de três versões para cima. Ou existem opções?"
No contexto do projeto aberto do Kubernetes, as correções de software geralmente são lançadas na próxima versão, às vezes abrangem uma ou duas versões intermediárias anteriores, o que cobre até seis meses atrás.
A Red Hat se orgulha de lançar correções críticas antes dos outros e de oferecer suporte por um período muito mais longo. Tomemos como exemplo a vulnerabilidade com elevação de privilégios no Kubernetes (): ela foi descoberta no Kubernetes 1.11, e as correções para versões anteriores foram lançadas apenas até a versão 1.10.11, deixando essa vulnerabilidade em todas as versões anteriores do Kubernetes, de 1.x a 1.9.
Por sua vez, (que utiliza o Kubernetes 1.2), abrangendo nove lançamentos do OpenShift e demonstrando claramente o cuidado com os clientes (mais detalhes ).
Como o OpenShift e a Red Hat impulsionam o Kubernetes
A Red Hat ocupa o segundo lugar em termos da contribuição de código para o projeto de código aberto Kubernetes, ficando atrás apenas do Google, sendo que 3 dos 5 desenvolvedores mais produtivos são funcionários da Red Hat. Outro fato pouco conhecido: muitas funcionalidades críticas foram introduzidas no Kubernetes por iniciativa da Red Hat, especificamente, como por exemplo:
- RBAC. Não havia funcionalidades RBAC (ClusterRole, ClusterRoleBinding) no Kubernetes até que engenheiros da Red Hat decidiram implementá-las como parte da plataforma, e não como uma funcionalidade adicional do OpenShift. A Red Hat tem medo de melhorar o Kubernetes? Claro que não, pois a Red Hat segue rigorosamente os princípios de código aberto e não joga jogos de Open Core. Melhorias e inovações que são implementadas a nível das comunidades de desenvolvimento, e não com base em propriedade, tornam-se mais viáveis e ganham uma adoção mais ampla, o que se alinha perfeitamente com nossa principal meta – tornar o software de código aberto mais útil para nossos clientes.
- Políticas de segurança para pods (Pod Security Policies). Inicialmente, essa concepção de execução segura de aplicações dentro dos pods foi implementada no OpenShift sob o nome de SCC (Security Context Constraints). Assim como no exemplo anterior, a Red Hat decidiu introduzir esses avanços no projeto de código aberto Kubernetes, para que todos os interessados pudessem utilizá-los.
Essa série de exemplos poderia continuar, mas apenas queríamos mostrar que a Red Hat realmente se esforça para desenvolver o Kubernetes e torná-lo melhor para todos.
É claro que o OpenShift é Kubernetes. Mas quais são as diferenças? 🙂
Esperamos que, ao chegar até este ponto, você tenha compreendido que o Kubernetes é o componente principal do OpenShift. Principal, mas certamente não o único. Em outras palavras, ao simplesmente instalar o Kubernetes, você não obterá uma plataforma corporativa de classe. Você precisará adicionar autenticação, rede, segurança, monitoramento, gerenciamento de logs e muito mais. Além disso, será necessário fazer uma difícil escolha entre as muitas ferramentas disponíveis (para avaliar a diversidade do ecossistema, basta dar uma olhada na ) e de alguma forma garantir a consistência e sinergia para que elas funcionem como um todo. Além disso, você precisará realizar atualizações e testes de regressão regularmente sempre que uma nova versão de qualquer um dos componentes utilizados for lançada. Ou seja, além de criar e manter a própria plataforma, você também terá que lidar com todo esse software. Dificilmente sobrará muito tempo para resolver questões de negócios e alcançar vantagens competitivas.
No caso do OpenShift, a Red Hat assume todas essas complexidades e simplesmente fornece uma plataforma funcionalmente completa, que inclui não apenas o próprio Kubernetes, mas também um conjunto completo de ferramentas de código aberto que transformam o Kubernetes em uma verdadeira solução de classe empresarial, que pode ser imediatamente e tranquilamente colocada em produção. E, é claro, se você tiver suas próprias pilhas tecnológicas, poderá integrar o OpenShift às soluções já existentes.
Dê uma olhada na ilustração acima: tudo que está fora do retângulo do Kubernetes representa as áreas onde a Red Hat adiciona funcionalidades que não estão presentes no Kubernetes, por design. E agora, vamos examinar as principais dessas áreas.
1. Um sistema operacional confiável como base: RHEL CoreOS ou RHEL
A Red Hat é um fornecedor líder de distribuições Linux para aplicações empresariais críticas há mais de 20 anos. A experiência acumulada e continuamente atualizada nesta área nos permite oferecer uma base verdadeiramente confiável e segura para a operação industrial de contêineres. O RHEL CoreOS utiliza o mesmo núcleo que o RHEL, mas é otimizado principalmente para tarefas como execução de contêineres e operação em clusters Kubernetes: seu tamanho reduzido e imutabilidade simplificam a instalação de clusters, a escalabilidade automática, a implantação de patches, etc. Todas essas funcionalidades fazem dele a base ideal para proporcionar a mesma experiência ao usuário ao trabalhar com OpenShift em diversos ambientes de computação, desde hardware dedicado até nuvem privada e pública.
2. Automação de Operações de TI
A automação dos processos de instalação e operações do segundo dia (ou seja, operação diária) é um dos pontos fortes do OpenShift, que facilita significativamente a administração, atualização e manutenção do desempenho da plataforma de contêineres em seu mais alto nível. Isso é alcançado por meio do suporte a operadores Kubernetes no nível do núcleo do OpenShift 4.
O OpenShift 4 também é um verdadeiro ecossistema de soluções baseadas em operadores Kubernetes, desenvolvidas tanto pela Red Hat quanto por parceiros externos (veja Red Hat, ou loja de operadores , criado pela Red Hat para desenvolvedores de terceiros).
O catálogo integrado do OpenShift 4 inclui mais de 180 operadores Kubernetes
3. Ferramentas para Desenvolvedores
Desde 2011, o OpenShift está disponível como uma plataforma PaaS (Platform-as-a-Service), que simplifica muito a vida dos desenvolvedores, ajudando-os a se concentrar na criação de código e oferecendo suporte embutido a linguagens de programação como Java, Node.js, PHP, Ruby, Python, Go, além de serviços de integração e entrega contínuas CI/CD, bancos de dados, etc. O OpenShift 4 oferece , incluindo mais de 100 serviços baseados em operadores Kubernetes, desenvolvidos pela Red Hat e nossos parceiros.
Ao contrário do Kubernetes, o OpenShift 4 possui uma interface gráfica especial (), ajudando os desenvolvedores a implantar aplicações de diversas fontes (git, repositórios externos, Dockerfile, etc.) em seus namespaces sem esforço adicional e visualizando claramente as relações entre os componentes da aplicação.
Além disso, o OpenShift oferece um conjunto de ferramentas de desenvolvimento Codeready, que inclui, entre outros, , uma IDE totalmente containerizada com interface web, que funciona diretamente sobre o OpenShift e implementa a abordagem 'IDE como serviço'. Por outro lado, para aqueles que desejam trabalhar estritamente em modo local, existe o Codeready Containers – uma versão totalmente funcional do OpenShift 4, que pode ser implantada em um notebook.
IDE integrada 'como serviço' para desenvolvimento eficiente na plataforma Kubernetes/OpenShift.
O OpenShift oferece, diretamente da caixa, um sistema completo de CI/CD, baseado em Jenkins containerizado e plugin para trabalhar com pipelines, ou um sistema CI/CD voltado para Kubernetes (atualmente na versão Tech preview). Ambas as soluções se integram totalmente ao console do OpenShift, permitindo acionar gatilhos de pipelines, visualizar implantações, logs, etc.
4. Ferramentas para Aplicações
O OpenShift permite implantar tanto aplicações stateful tradicionais quanto soluções orientadas para a nuvem baseadas em novas arquiteturas, como microsserviços ou serverless. A solução OpenShift Service Mesh oferece diretamente ferramentas essenciais para a gestão de microsserviços, como Istio, Kiali e Jaeger. Por sua vez, a solução OpenShift Serverless inclui não apenas o Knative, mas também ferramentas desenvolvidas em uma iniciativa conjunta com a Microsoft, como o Keda, para fornecer funcionalidades do Azure na plataforma OpenShift.
A solução integrada OpenShift ServiceMesh (Istio, Kiali, Jaeger) é útil para o desenvolvimento de microsserviços.
Para fechar a lacuna entre aplicativos legados e containers, o OpenShift agora permite a migração de máquinas virtuais para a plataforma OpenShift usando Container Native Virtualization (atualmente na versão Tech Preview), tornando os aplicativos híbridos uma realidade e facilitando sua transferência entre diferentes nuvens, tanto privadas quanto públicas.
Máquina virtual Windows 2019 Virtual, executada no OpenShift através do Container Native Virtualization (atualmente na versão Tech preview).
5. Ferramentas para Clusters
Toda plataforma corporativa deve ter serviços de monitoramento e registro centralizado, mecanismos de segurança, autenticação e autorização, além de ferramentas de gerenciamento de rede. O OpenShift oferece tudo isso prontamente, e tudo com código totalmente aberto, incluindo soluções como ElasticSearch, Prometheus e Grafana. Todas essas soluções vêm com painéis informativos, métricas e alertas já configurados e ajustados com base na vasta experiência da Red Hat em monitoramento de clusters, permitindo que você controle e acompanhe a operação do seu ambiente de produção desde o início.
O OpenShift também oferece, de forma nativa, funcionalidades importantes para clientes corporativos, como autenticação com um provedor oauth integrado, integração com provedores de credenciais, incluindo LDAP, Active Directory, OpenID Connect, entre muitos outros.
Painel de controle Grafana pré-configurado para monitoramento do cluster OpenShift
Mais de 150 métricas e alertas Prometheus pré-configurados para monitoramento do cluster OpenShift
Continua
A rica funcionalidade da solução e a ampla experiência da Red Hat em Kubernetes são as razões pelas quais o OpenShift dominou o mercado, como mostrado na imagem abaixo (mais detalhes ).
«Atualmente, a Red Hat lidera o mercado com uma participação de 44%.
A empresa está colhendo os frutos de sua estratégia de vendas, que envolve ativamente os clientes, onde primeiro consultam e treinam desenvolvedores corporativos, e depois avançam para a monetização à medida que a empresa começa a implementar containers em produção».
(Fonte: )
Esperamos que você tenha gostado deste artigo. Nos próximos posts desta série, iremos detalhar as vantagens do OpenShift em comparação ao Kubernetes em cada uma das categorias discutidas aqui.
Fonte: habr.com
