“Qual é a diferença entre Kubernetes e OpenShift?” – esta questão surge com invejável consistência. Embora, na realidade, seja como perguntar como um carro difere de um motor. Se continuarmos a analogia, então um carro é um produto acabado, você pode usá-lo imediatamente, literalmente: entre e vá embora. Por outro lado, para que um motor o leve a algum lugar, ele deve primeiro ser complementado com muitas outras coisas para, no final das contas, obter o mesmo carro.
Portanto, Kubernetes é o motor em torno do qual é montado o carro (plataforma) da marca OpenShift, que leva você ao seu objetivo.
Neste artigo queremos lembrá-lo e examinar os seguintes pontos-chave com um pouco mais de detalhes:
- Kubernetes é o coração da plataforma OpenShift e é 100% certificado como Kubernetes, totalmente open source e sem a menor natureza proprietária. Brevemente:
- A API do cluster OpenShift é XNUMX% Kubernetes.
- Se o contêiner for executado em qualquer outro sistema Kubernetes, ele será executado no OpenShift sem nenhuma alteração. Não há necessidade de fazer alterações nos aplicativos.
- OpenShift não apenas adiciona recursos e funcionalidades úteis ao Kubernetes. Assim como um carro, o OpenShift sai da caixa, pode ser colocado em produção imediatamente e, como mostraremos a seguir, facilita muito a vida do desenvolvedor. É por isso que o OpenShift é uma em cada duas pessoas. É uma plataforma PaaS de classe empresarial bem-sucedida e bem conhecida do ponto de vista do desenvolvedor. E, ao mesmo tempo, é uma solução Container-as-a-Service superconfiável do ponto de vista da operação industrial.
OpenShift é Kubernetes com certificação 100% CNCF
OpenShift é baseado em . Portanto, após o treinamento adequado, os usuários ficam maravilhados com o poder do kubectl. E aqueles que mudaram do cluster Kubernetes para o OpenShift costumam dizer o quanto realmente gostam disso, depois de redirecionar o kubeconfig para o cluster OpenShift, todos os scripts existentes funcionam perfeitamente.
Você provavelmente já ouviu falar do utilitário de linha de comando do OpenShift chamado OC. É totalmente compatível com comandos do kubectl, além de oferecer vários ajudantes úteis que serão úteis ao executar uma série de tarefas. Mas primeiro, um pouco mais sobre a compatibilidade do OC e do kubectl:
Comandos kubectl
Equipes de CO
kubectl obter pods
oc obter pods
kubectl obtém namespaces
oc obter namespaces
kubectl create -f implantação.yaml
oc create -f implantação.yaml
Veja como são os resultados do uso do kubectl na API OpenShift:
• kubectl get pods – retorna pods conforme esperado.
• kubectl get namespaces – retorna namespaces conforme esperado.
O comando kubectl create -f mydeployment.yaml cria recursos kubernetes como em qualquer outra plataforma Kubernetes, conforme mostrado no vídeo abaixo:
Em outras palavras, todas as APIs do Kubernetes estão totalmente disponíveis no OpenShift, mantendo 100% de compatibilidade. Por isso .
OpenShift adiciona recursos úteis ao Kubernetes
As APIs do Kubernetes estão 100% disponíveis no OpenShift, mas o utilitário padrão do Kubernetes, kubectl, claramente carece de funcionalidade e conveniência. É por isso que a Red Hat adicionou recursos úteis e ferramentas de linha de comando ao Kubernetes, como OC (abreviação de cliente OpenShift) e ODO (OpenShift DO, este utilitário é voltado para desenvolvedores).
1. Utilitário OC - uma versão mais poderosa e conveniente do Kubectl
Por exemplo, ao contrário do kubectl, ele permite criar novos namespaces e alternar contextos facilmente, e também oferece uma série de comandos úteis para desenvolvedores, como construir imagens de contêiner e implantar aplicativos diretamente do código-fonte ou binários (fonte para imagem, s2i).
Vejamos exemplos de como os auxiliares integrados e a funcionalidade avançada do utilitário OC ajudam a simplificar o trabalho diário.
O primeiro exemplo é o gerenciamento de namespace. Cada cluster Kubernetes sempre possui vários namespaces. Eles geralmente são usados para criar ambientes de desenvolvimento e produção, mas também podem ser usados, por exemplo, para fornecer a cada desenvolvedor uma sandbox pessoal. Na prática, isso faz com que o desenvolvedor tenha que alternar frequentemente entre namespaces, já que o kubectl é executado no contexto do espaço atual. Portanto, no caso do kubectl, as pessoas usam ativamente scripts auxiliares para isso. Mas ao usar OC, para mudar para o espaço desejado, basta dizer “oc project namespace”.
Não lembra como é chamado o namespace que você precisa? Não tem problema, basta digitar “oc get projects” para exibir a lista completa. Você está cético e está se perguntando como isso funcionará se você tiver acesso apenas a um subconjunto limitado de namespaces no cluster? Bem, porque o kubectl só faz isso corretamente se o RBAC permitir que você veja todos os espaços no cluster e, em clusters grandes, nem todos recebem essas permissões. Então, respondemos: para o OC isso não é problema nenhum e ele produzirá facilmente uma lista completa em tal situação. São estas pequenas coisas que compõem a orientação corporativa do Openshift e a boa escalabilidade desta plataforma em termos de utilizadores e aplicações
2. ODO – uma versão melhorada do kubectl para desenvolvedores
Outro exemplo de melhorias do Red Hat OpenShift em relação ao Kubernetes é o utilitário de linha de comando ODO. Ele foi projetado para desenvolvedores e permite implantar rapidamente código local em um cluster OpenShift remoto. Ele também pode agilizar processos internos para sincronizar instantaneamente todas as alterações de código em contêineres em um cluster OpenShift remoto sem precisar reconstruir, registrar e reimplantar imagens.
Vejamos como OC e ODO facilitam o trabalho com contêineres e Kubernetes.
Basta comparar alguns fluxos de trabalho quando eles são criados com base no kubectl e quando OC ou ODO são usados.
• Implantação de código em OpenShift para quem não fala YAML:
Kubernetes/kubectl
$>git clone
1- Crie um Dockerfile que construa a imagem a partir do código
-----
DO nó
WORKDIR /usr/src/app
COPIAR pacote*.json ./
COPIE index.js ./
COPIAR ./app ./app
EXECUTAR instalação npm
EXPOR 3000
CMD [“npm”, “iniciar”] ————–
2- Construímos a imagem
$>construção do podman...
3- Faça login no registro
login do podman...
4- Coloque a imagem no registro
empurrar podman
5- Crie arquivos yaml para implantação de aplicativos (deployment.yaml, service.yaml, ingress.yaml) - este é o mínimo absoluto
6- Implante arquivos de manifesto:
Kubectl aplicar -f .
OpenShift/oc
$> oc novo aplicativo – nosso_nome_aplicativo
OpenShift/odo
$>git clone
$> odo criar componente nodejs myapp
$>odo push
• Mudança de contexto: altere o namespace de trabalho ou o cluster de trabalho.
Kubernetes/kubectl
1- Crie um contexto no kubeconfig para o projeto “myproject”
2- contexto de conjunto kubectl…
OpenShift/oc
oc projeto “meuprojeto”
Controle de qualidade: “Apareceu aqui um recurso interessante, ainda em versão alfa. Talvez possamos colocá-lo em produção?
Imagine estar sentado num carro de corrida e ouvir: “Instalámos um novo tipo de travões e, para ser honesto, a sua fiabilidade ainda não está boa... Mas não se preocupe, iremos melhorá-los ativamente durante o percurso. do campeonato”. O que você acha dessa perspectiva? Nós da Red Hat não estamos muito felizes. 🙂
Portanto, tentamos adiar as versões alfa até que estejam suficientemente maduras e tenhamos feito testes de batalha completos e sintamos que são seguras para uso. Normalmente, tudo passa primeiro pelo estágio Dev Preview e depois e só então sai como um lançamento público (GA), que já é tão estável que é adequado para produção.
Por que é que? Porque, como acontece com o desenvolvimento de qualquer outro software, nem todas as ideias iniciais no Kubernetes chegam à versão final. Ou alcançam-no e até mantêm a funcionalidade pretendida, mas a sua implementação é radicalmente diferente daquela na versão alfa. Com milhares e milhares de clientes Red Hat usando OpenShift para suportar cargas de trabalho de missão crítica, damos ênfase especial à estabilidade de nossa plataforma e ao suporte de longo prazo.
A Red Hat está comprometida em lançar o OpenShift com frequência e atualizar a versão do Kubernetes que o acompanha. Por exemplo, a versão GA atual do OpenShift 4.3 no momento da redação deste artigo inclui o Kubernetes 1.16, que está apenas uma unidade atrás da versão upstream do Kubernetes numerada 1.17. Portanto, estamos tentando fornecer ao cliente Kubernetes de classe empresarial e fornecer controle de qualidade adicional à medida que lançamos novas versões do OpenShift.
Correções de software: “Havia uma falha na versão do Kubernetes que temos em produção. E você só pode fechá-lo atualizando três versões. Ou há alguma opção?
No projeto de código aberto Kubernetes, as correções de software geralmente são lançadas como parte do próximo lançamento, às vezes cobrindo um ou dois lançamentos importantes anteriores, devolvendo a cobertura em apenas 6 meses.
A Red Hat se orgulha de lançar correções críticas mais cedo do que outras e de fornecer suporte por muito mais tempo. Tomemos, por exemplo, a vulnerabilidade de escalonamento de privilégios do Kubernetes (): foi descoberto no Kubernetes 1.11, e correções para versões anteriores foram lançadas apenas até a versão 1.10.11, deixando esta na lacuna em todas as versões anteriores do Kubernetes, de 1.x a 1.9.
Por sua vez, (Kubernetes 1.2 está lá), capturando nove versões do OpenShift e demonstrando claramente o cuidado com os clientes (mais detalhes ).
Como o OpenShift e o Red Hat estão impulsionando o Kubernetes
A Red Hat é a segunda maior contribuidora de software para o projeto de código aberto Kubernetes, atrás apenas do Google, com 3 dos 5 desenvolvedores mais prolíficos vindos da Red Hat. Outro fato pouco conhecido: muitas funções críticas surgiram no Kubernetes justamente por iniciativa da Red Hat, em particular, como:
- RBAC. O Kubernetes não tinha funções RBAC (ClusterRole, ClusterRoleBinding) até que os engenheiros da Red Hat decidiram implementá-las como parte da própria plataforma, e não como funcionalidade adicional do OpenShift. A Red Hat tem medo de melhorar o Kubernetes? Claro que não, porque a Red Hat segue estritamente os princípios de código aberto e não joga jogos Open Core. Melhorias e inovações impulsionadas por comunidades de desenvolvimento, em vez de comunidades proprietárias, são mais viáveis e adotadas de forma mais ampla, o que se alinha bem com nosso objetivo principal de tornar o software de código aberto mais útil para nossos clientes.
- Políticas de segurança para pods (Políticas de segurança de pod). Este conceito de execução segura de aplicativos dentro de pods foi originalmente implementado no OpenShift sob o nome SCC (Security Context Constraints). E como no exemplo anterior, a Red Hat decidiu introduzir esses desenvolvimentos no projeto aberto Kubernetes para que todos pudessem utilizá-los.
Esta série de exemplos poderia continuar, mas queríamos apenas mostrar que a Red Hat está realmente comprometida em desenvolver o Kubernetes e torná-lo melhor para todos.
Está claro que OpenShift é Kubernetes. Quais são as diferenças? 🙂
Esperamos que ao ler até aqui você tenha percebido que o Kubernetes é o componente principal do OpenShift. O principal, mas longe de ser o único. Em outras palavras, a simples instalação do Kubernetes não proporcionará uma plataforma de classe empresarial. Você precisará adicionar autenticação, rede, segurança, monitoramento, gerenciamento de log e muito mais. Além disso, você terá que fazer algumas escolhas difíceis entre o grande número de ferramentas disponíveis (para apreciar a diversidade do ecossistema, basta dar uma olhada ) e de alguma forma garantir consistência e coerência para que funcionem como um só. Além disso, você precisará realizar regularmente atualizações e testes de regressão sempre que uma nova versão de qualquer um dos componentes que você usa for lançada. Ou seja, além de criar e manter a própria plataforma, você também precisará lidar com todo esse software. É improvável que reste muito tempo para resolver problemas de negócios e obter vantagens competitivas.
Mas 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 todo o conjunto de ferramentas de código aberto necessárias que transformam o Kubernetes em uma verdadeira classe empresarial. solução que você pode lançar em produção imediatamente e com total tranquilidade. E, claro, se você tiver algumas de suas próprias pilhas de tecnologia, poderá integrar o OpenShift às soluções existentes.
Dê uma olhada na imagem acima: tudo que está fora do retângulo do Kubernetes é onde a Red Hat adiciona funcionalidades que o Kubernetes não possui, como dizem, por design. E agora veremos as principais dessas áreas.
1. SO robusto como base: RHEL CoreOS ou RHEL
A Red Hat é fornecedora líder de distribuições Linux para aplicativos essenciais aos negócios há mais de 20 anos. A nossa experiência acumulada e constantemente atualizada nesta área permite-nos oferecer uma base verdadeiramente fiável e de confiança para a operação industrial de contentores. O RHEL CoreOS usa o mesmo kernel do RHEL, mas é otimizado principalmente para tarefas como execução de contêineres e clusters Kubernetes: seu tamanho reduzido e imutabilidade facilitam a configuração de clusters, escalonamento automático, implantação de patches, etc. uma base ideal para oferecer a mesma experiência de usuário com OpenShift em uma ampla variedade de ambientes de computação, desde bare metal até nuvem privada e pública.
2. Automação das operações de TI
A automação dos processos de instalação e das operações do dia 4 (ou seja, operações diárias) é o ponto forte do OpenShift, tornando muito mais fácil administrar, atualizar e manter o desempenho da plataforma de contêiner no mais alto nível. Isto é conseguido através do suporte para operadores Kubernetes no nível do kernel OpenShift XNUMX.
OpenShift 4 também é todo um ecossistema de soluções baseadas em operadores Kubernetes, desenvolvidas pela própria Red Hat e por parceiros terceirizados (consulte. Red Hat, ou loja de operadora , criado pela Red Hat para desenvolvedores terceirizados).
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 facilita muito a vida dos desenvolvedores, ajuda-os a focar na codificação e oferece suporte nativo para linguagens de programação como Java, Node.js. , PHP, Ruby, Python, Go, bem como integração contínua de CI/CD e serviços de entrega, bancos de dados, etc. OpenShift 4 oferece , que inclui 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 GUI dedicada (), que ajuda os desenvolvedores a implantar facilmente aplicativos de várias fontes (git, registros externos, Dockerfile etc.) em seus namespaces e visualiza claramente os relacionamentos entre os componentes do aplicativo.
Além disso, OpenShift oferece um conjunto de ferramentas de desenvolvimento Codeready, que, em particular, inclui , um IDE totalmente conteinerizado com uma interface web que roda diretamente sobre o OpenShift e implementa uma abordagem IDE como serviço. Por outro lado, para quem deseja trabalhar estritamente em modo local, existe o Codeready Containers, uma versão totalmente funcional do OpenShift 4 que pode ser implantada em um laptop.
IDE integrado como serviço para desenvolvimento eficiente na plataforma Kubernetes/OpenShift
OpenShift oferece um sistema CI/CD completo pronto para uso, baseado em Jenkins conteinerizado e um plugin para trabalhar com pipelines ou um sistema CI/CD orientado a Kubernetes (atualmente na versão de visualização técnica). Ambas as soluções integram-se totalmente ao console OpenShift, permitindo executar gatilhos de pipeline, visualizar implantações, logs e muito mais.
4. Ferramentas de aplicação
O OpenShift permite implantar aplicativos tradicionais com estado e soluções baseadas em nuvem baseadas em novas arquiteturas, como microsserviços ou sem servidor. A solução OpenShift Service Mesh vem pronta para uso com ferramentas essenciais para manutençã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 como o Keda, criadas como parte de uma iniciativa conjunta com a Microsoft para fornecer funções Azure na plataforma OpenShift.
A solução integrada OpenShift ServiceMesh (Istio, Kiali, Jaeger) será útil no desenvolvimento de microsserviços
Para preencher a lacuna entre aplicativos legados e contêineres, o OpenShift agora permite a migração de máquinas virtuais para a plataforma OpenShift usando Container Native Virtualization (atualmente em TechPreview), tornando os aplicativos híbridos uma realidade e facilitando sua migração entre diferentes nuvens, tanto privadas quanto públicas.
Máquina virtual virtual Windows 2019 em execução no OpenShift via Container Native Virtualization (atualmente na versão Tech Preview)
5. Ferramentas para clusters
Qualquer plataforma de classe empresarial deve ter serviços de monitoramento e registro centralizados, mecanismos de segurança, autenticação e autorização e ferramentas de gerenciamento de rede. E o OpenShift oferece tudo isso pronto para uso, e é tudo 100% de código aberto, incluindo soluções como ElasticSearch, Prometheus, Grafana. Todas essas soluções vêm com painéis, métricas e alertas que já foram criados e configurados usando a ampla experiência em monitoramento de cluster da Red Hat, permitindo que você controle e monitore efetivamente seu ambiente de produção desde o início.
O OpenShift também vem com itens importantes para clientes corporativos, como autenticação com um provedor oauth integrado, integração com provedores de credenciais, incluindo LDAP, ActiveDirectory, OpenID Connect e muito mais.
Painel Grafana pré-configurado para monitoramento de cluster OpenShift
Mais de 150 métricas e alertas pré-configurados do Prometheus para monitoramento de cluster OpenShift
Para ser continuado
A rica funcionalidade da solução e a vasta experiência da Red Hat na área de Kubernetes são as razões pelas quais o OpenShift alcançou uma posição dominante no mercado, conforme mostrado na figura abaixo (leia mais ).
“A Red Hat atualmente lidera o mercado com uma participação de 44%.
A empresa está colhendo os benefícios de sua estratégia de vendas centrada no cliente, onde primeiro consulta e treina desenvolvedores corporativos e depois passa para a monetização à medida que a empresa começa a implantar contêineres na produção.”
(Fonte: )
Esperamos que você tenha gostado deste artigo. Em postagens futuras desta série, examinaremos mais de perto as vantagens do OpenShift sobre o Kubernetes em cada uma das categorias discutidas aqui.
Fonte: habr.com