OpenShift como uma versão corporativa do Kubernetes

"Qual é a diferença entre Kubernetes e OpenShift?" - Esta questão surge com constância invejável. 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: você se sentou e foi embora. Por outro lado, para que o motor o leve a algum lugar, primeiro ele deve ser complementado com várias outras coisas para obter o mesmo carro.



Portanto, o Kubernetes é um mecanismo desse tipo, em torno do qual é montado um automóvel (plataforma) da marca OpenShift, que o leva ao objetivo.

Neste artigo, queremos lembrar e analisar com mais detalhes os seguintes pontos-chave:

  • O Kubernetes está no coração da plataforma OpenShift e é 100% certificado pela Kubernetes, de código aberto e sem a menor propriedade. Em resumo:
    • API OpenShift – Kubernetes.
    • Kubernetes, - OpenShift. .
  • OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF


O OpenShift é baseado no Kubernetes Certified . Portanto, após o treinamento apropriado, os usuários admiram o poder do kubectl. E aqueles que mudaram para o OpenShift com o Kubernetes Cluster costumam dizer como realmente gostam depois de redirecionar o kubeconfig para o cluster do OpenShift, todos os scripts disponíveis funcionam perfeitamente.

Você provavelmente já ouviu falar sobre o utilitário de linha de comando OpenShift chamado OC. É totalmente compatível com os comandos kubectl, além de oferecer vários helper'ov úteis que são úteis ao executar várias tarefas. Mas primeiro, um pouco mais sobre a compatibilidade com OC e kubectl:

Equipas KubectlEquipes OC
kubectl get podsoc obter pods
kubectl obter espaços para nomeoc obter namespaces
kubectl create -f deployment.yamloc create -f deployment.yaml

Veja como são os resultados do uso do kubectl na API do OpenShift:

• kubectl get pods - espera-se que ele retorne pods.



• kubectl get namespaces - muito provavelmente retorna namespaces.


O comando kubectl create -f mydeployment.yaml cria recursos kubernetes como em qualquer outra plataforma Kubernetes, como mostra o vídeo abaixo:


Em outras palavras, todas as APIs do Kubernetes são totalmente acessíveis no OpenShift com 100% de compatibilidade. É por isso que o OpenShift é reconhecido pela CNC Native (Cloud Native Computing Foundation) como uma plataforma Kubernetes certificada . 

OpenShift suporta Kubernetes com recursos úteis


As APIs do Kubernetes estão 100% disponíveis no OpenShift, mas o utilitário kubectl normal do Kubernetes está claramente sem funcionalidade e conveniência. Portanto, a Red Hat adicionou o Kubernetes com recursos úteis e ferramentas de linha de comando, como OC (abreviação de cliente OpenShift) e ODO (OpenShift DO, este utilitário é destinado a desenvolvedores).

1. O utilitário OC - uma versão mais poderosa e conveniente do Kubectl


Por exemplo, ao contrário do kubectl, ele permite criar novos espaços para nome e alternar facilmente contextos, além de oferecer vários comandos úteis para desenvolvedores, por exemplo, para criar imagens de contêiner e implantar aplicativos diretamente do código-fonte ou de arquivos binários (fonte para imagem, s2i).

Vejamos exemplos de como o auxiliar incorporado e a funcionalidade avançada do utilitário OC ajudam a simplificar o trabalho diário.

O exemplo um é o gerenciamento de namespace. Cada cluster Kubernetes sempre tem vários espaços para nome. Geralmente eles são usados ​​para criar ambientes de desenvolvimento e produção, mas também podem ser usados ​​para, por exemplo, dar a cada desenvolvedor uma "caixa de areia" pessoal. Na prática, isso leva ao fato de que o desenvolvedor geralmente precisa alternar entre espaços para nome, pois o kubectl funciona no contexto do espaço atual. Portanto, no caso do kubectl, as pessoas usam ativamente scripts auxiliares para isso. Porém, ao usar o OC para alternar para o espaço desejado, basta dizer "oc project namespace_".

Não se lembra como o espaço para nome é chamado? Não tem problema, basta digitar “oc get projects” para exibir uma lista completa. Cético, imaginando como isso funcionará se você tiver acesso apenas a um subconjunto limitado de namespaces no cluster? Bem, porque o kubectl faz isso corretamente, apenas se o RBAC permitir que você veja todos os espaços no cluster e em clusters grandes, nem todos concedem essa autoridade. Portanto, respondemos: para OC, isso não é um problema e fornecerá facilmente uma lista completa nessa situação. É a partir dessa insignificância que o foco corporativo da Openshift e a boa escalabilidade dessa plataforma em termos de usuários e aplicativos são criados

2. ODO - uma versão aprimorada do kubectl para desenvolvedores


Outro exemplo das melhorias do Red Hat OpenShift sobre o Kubernetes é o utilitário de linha de comando ODO. Ele é destinado a desenvolvedores e permite implantar rapidamente o código local em um cluster OpenShift remoto. Além disso, ele pode ser usado para otimizar processos internos para sincronizar instantaneamente todas as alterações de código com contêineres em um cluster OpenShift remoto sem precisar remontar, colocar no registro e reimplementar imagens.

Vamos ver como OC e ODO facilitam o contêiner e o Kubernetes.

Basta comparar alguns fluxos de trabalho quando construídos com base no kubectl e quando OC ou ODO são usados.

• Implantação de código no OpenShift para quem não fala o idioma YAML:

Kubernetes / kubectl$> git clone github.com/sclorg/nodejs-ex.git
1- Dockerfile,
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ]
————–
2-
$> podman build …
3-
podman login …
4-
podman push
5- yaml- (deployment.yaml, service.yaml, ingress.yaml) –
6- manifest-:
Kubectl apply -f .
OpenShift / oc$> oc new-app github.com/sclorg/nodejs-ex.git – __
OpenShift / odo$> git clone github.com/sclorg/nodejs-ex.git
$> odo create component nodejs myapp
$> odo push

• : .

Kubernetes / kubectl1- kubeconfig “myproject”
2- kubectl set-context …
OpenShift / ococ project “myproject”

: « , -. ?»


Imagine que você está sentado em um carro de corrida e eles dizem: "Nós colocamos um novo tipo de freio aqui e, francamente, eles ainda não estão bem com confiabilidade ... Mas não se preocupe, nós os refinaremos ativamente no decorrer do campeonato". Como você gosta dessa perspectiva? Nós da Red Hat, de alguma forma, não somos muito. :)

Portanto, tentamos evitar as versões alfa até que estejam maduras o suficiente e não realizamos testes de combate completos e sentimos que eles podem ser usados ​​com segurança. Geralmente, tudo passa primeiro pelo estágio de Visualização do desenvolvedor, depois pelo Tech Preview, e só então sai na forma de uma disponibilidade pública ( disponibilidade geral) (GA), que já é estável o suficiente para ser adequada à produção.

Por que é que? Porque, como no desenvolvimento de qualquer outro software, nem todas as idéias iniciais no Kubernetes chegam à versão final. Ou eles alcançam e até mantêm a funcionalidade pretendida, mas sua implementação é fundamentalmente diferente daquela na versão alfa. Como milhares e milhares de clientes da Red Hat usam o OpenShift para dar suporte a tarefas críticas, colocamos ênfase especial na estabilidade da nossa plataforma e no suporte a longo prazo.

A Red Hat lança deliberadamente lançamentos frequentes do OpenShift e atualiza sua versão do Kubernetes. Por exemplo, no momento da redação deste artigo, a versão GA do OpenShift 4.3 inclui o Kubernetes 1.16, que é apenas uma unidade atrás da versão upstream do Kubernetes 1.17. Assim, tentamos oferecer ao cliente Kubernetes de classe corporativa e fornecer controle de qualidade adicional no processo de lançamento de novas versões do OpenShift.

Correções de software: “Havia um buraco nessa versão do Kubernetes que temos em produção. E você pode fechá-lo apenas atualizando três versões. Ou existem opções?


Como parte do projeto de código-fonte aberto Kubernetes, as correções de software geralmente são lançadas como parte da próxima versão, às vezes cobrem uma ou duas versões intermediárias anteriores, o que dá cobertura apenas 6 meses atrás.

A Red Hat se orgulha de lançar correções críticas mais cedo do que outras e de fornecer suporte por um período muito maior. Tomemos, por exemplo, a vulnerabilidade de escalonamento de privilégios do Kubernetes ( CVE-2018-1002105 ): foi descoberta no Kubernetes 1.11 e os patches para versões anteriores foram liberados apenas para a versão 1.10.11, deixando esse buraco em todas as versões anteriores do Kubernetes, a partir de 1 .x a 1,9.

Por sua vez, a Red Hat corrigiu o OpenShift para a versão 3.2(O Kubernetes 1.2 está lá), capturando nove lançamentos do OpenShift e demonstrando o atendimento ao cliente (mais informações aqui ).

Como o OpenShift e a Red Hat avançam o Kubernetes


A Red Hat ocupa o segundo lugar em termos de contribuições de software para o Kubernetes open source, perdendo apenas para o Google, com três dos cinco desenvolvedores mais prolíficos trabalhando para a Red Hat. Outro fato pouco conhecido: muitas funções críticas apareceram no Kubernetes precisamente por iniciativa da Red Hat, em particular, como:

  • RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
  • Políticas de segurança para pods (Políticas de segurança de pods). Inicialmente, esse conceito de execução segura de aplicativo dentro de pods foi implementado no OpenShift sob o nome SCC (Security Context Constraints). E, como no exemplo anterior, a Red Hat decidiu introduzir esses desenvolvimentos no projeto Kubernetes de código aberto, para que todos pudessem usá-los.

Essa série de exemplos pode ser continuada, mas queríamos apenas mostrar que a Red Hat está realmente se esforçando para desenvolver o Kubernetes e torná-lo melhor para todos.

Claramente, o OpenShift é o Kubernetes. E quais são as diferenças? :)


Esperamos que, depois de ler até este ponto, você tenha percebido que o Kubernetes é o principal componente do OpenShift. Básico, mas não o único. Em outras palavras, ao instalar o Kubernetes, você não terá uma plataforma de classe empresarial. Você precisará adicionar autenticação, rede, segurança, monitoramento, gerenciamento de logs e muito mais. Além disso, você terá que fazer uma escolha difícil do grande número de ferramentas disponíveis (para avaliar a diversidade do ecossistema, basta olhar para o diagrama do CNCF) e de alguma forma garantir coerência e coerência para que funcionem como um todo. Além disso, você deverá executar regularmente testes de atualização e regressão quando uma nova versão de qualquer componente usado 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 haja muito tempo aqui para resolver problemas de negócios e obter vantagens competitivas.

Mas no caso do OpenShift, a Red Hat resolve todas essas dificuldades e simplesmente oferece uma plataforma funcionalmente completa, que inclui não apenas o Kubernetes, mas também todo o conjunto de ferramentas de código aberto necessárias que transformam o Kubernetes em uma solução real de classe empresarial que pode imediatamente e completamente calmamente em produção. E, é claro, se você possui alguma das suas pilhas de tecnologia, pode incorporar o OpenShift nas soluções existentes.


O OpenShift é uma plataforma inteligente do Kubernetes.

Dê uma olhada na figura acima: tudo o que está fora do retângulo do Kubernetes é a área em que a Red Hat adiciona funcionalidades que o Kubernetes não possui, que é chamado por design. E agora vamos considerar as principais dessas áreas.

1. Sistema operacional confiável como base: RHEL CoreOS ou RHEL


Por mais de 20 anos, a Red Hat é fornecedora líder de distribuições Linux para aplicativos de negócios de missão crítica. A experiência adquirida e constantemente atualizada nessa área nos permite oferecer uma base verdadeiramente confiável para a operação industrial de contêineres. O RHEL CoreOS usa o mesmo kernel que o RHEL, mas é otimizado principalmente para tarefas como executar contêineres e trabalhar em clusters Kubernetes: seu tamanho e imutabilidade reduzidos simplificam a instalação do cluster, o dimensionamento automático, a implantação de patches etc. Todos esses recursos o tornam a base ideal para obter a mesma experiência do usuário ao trabalhar com o OpenShift em uma ampla variedade de ambientes de computação, de bare metal a nuvens públicas e privadas.

2. Automação de operações de TI


A automação dos processos e operações de instalação do segundo dia (ou seja, operação diária) é um passatempo OpenShift que facilita muito a administração, atualização e manutenção da plataforma de contêineres no nível mais alto. Isso é conseguido ao oferecer suporte aos operadores Kubernetes no nível principal do OpenShift 4. O

OpenShift 4 também é um ecossistema inteiro de soluções baseadas nos operadores Kubernetes, desenvolvidos por parceiros da Red Hat e de terceiros (consulte o diretório do operador da Red Hat ou a loja do operador operatorhub.io , criado pela Red Hat para desenvolvedores de terceiros).


O Diretório Integrado do OpenShift 4 inclui mais de 180 operadores Kubernetes

3. Ferramentas de Desenvolvedor


Desde 2011, o OpenShift está disponível como uma plataforma PaaS (plataforma como serviço), o que simplifica bastante a vida dos desenvolvedores, os ajuda a focar na criação de código e oferece suporte interno para linguagens de programação como Java, Node.js, PHP, Ruby, Python, Go, bem como serviços contínuos de integração e entrega de CI / CD, bancos de dados, etc. O OpenShift 4 oferece um extenso catálogo 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 interface gráfica especial ( Developer Console), que ajuda os desenvolvedores a implantar facilmente aplicativos em seus namespaces de várias fontes (git, registros externos, Dockerfile etc.) e visualizar visualmente as conexões entre os componentes do aplicativo.


O Developer Console visualiza os componentes do aplicativo e simplifica o trabalho com o Kubernetes.Além

disso, o OpenShift oferece um conjunto de ferramentas de desenvolvimento Codeready, que incluem o Codeready Workspaces , um IDE baseado na Web totalmente em contêiner que é executado diretamente no OpenShift e implementa a abordagem semelhante ao IDE serviço". Por outro lado, para quem deseja trabalhar estritamente no modo local, existe o Codeready Containers - uma versão totalmente funcional do OpenShift 4 que pode ser implantada em um laptop.


“IDE como serviço” integrado para o desenvolvimento eficiente da plataforma Kubernetes / OpenShift.Pronto

para uso, o OpenShift oferece um sistema completo de CI / CD, baseado no Jenkins em contêiner e no plug-in DSL para pipelines ou no sistema Tekton baseado em CI / CD da Kubernetes (por enquanto na versão de visualização técnica). Ambas as soluções são totalmente integradas ao console do OpenShift, permitindo executar gatilhos de pipeline, visualizar implantações, logs etc.

4. Ferramentas para aplicações


O OpenShift permite implantar aplicativos stateful tradicionais e soluções baseadas em nuvem com base em novas arquiteturas, como microsserviços ou sem servidor. A solução OpenShift Service Mesh pronta para uso é essencial para oferecer suporte a ferramentas 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 do Azure na plataforma OpenShift.


Uma solução integrada do OpenShift ServiceMesh (Istio, Kiali, Jaeger) é útil no desenvolvimento de microsserviços.Para

diminuir a lacuna entre aplicativos e contêineres herdados, o OpenShift agora permite migrar máquinas virtuais para a plataforma OpenShift usando o Container Native Virtualization (enquanto na versão no TechPreview), transformando aplicativos híbridos em realidade e facilitando a transferência entre nuvens diferentes, tanto privadas quanto públicas.


Máquina virtual virtual do Windows 2019 em execução no OpenShift por meio da virtualização nativa de contêiner (atualmente na versão de visualização técnica)

5. Ferramentas para clusters


Qualquer plataforma de classe corporativa deve ter serviços de monitoramento e registro centralizado, mecanismos de segurança, autenticação e autorização e ferramentas de gerenciamento de rede. E o OpenShift fornece tudo isso pronto para uso, e tudo isso é 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á estão configurados e configurados com base na extensa experiência de monitoramento de cluster da Red Hat, que permite monitorar e rastrear efetivamente seu ambiente de produção desde os primeiros minutos.

O OpenShift também tem coisas importantes para o cliente corporativo, como autenticação com o provedor de oauth integrado, integração com provedores de credenciais, incluindo LDAP, ActiveDirectory, OpenID Connect e muito mais.


Painel Grafana pré-configurado para monitorar um cluster OpenShift


Mais de 150 métricas e alertas pré-configurados do Prometheus para monitorar um cluster OpenShift

Continua


A rica funcionalidade da solução e a vasta experiência da Red Hat no campo do Kubernetes são justamente por esses motivos que o OpenShift assumiu uma posição dominante no mercado, como mostra a figura abaixo (mais detalhes aqui ).


“Atualmente, a Red Hat lidera o mercado com uma participação de 44%.
A empresa está colhendo os benefícios de sua estratégia de vendas com a participação ativa nos assuntos dos clientes, na qual aconselha e treina primeiro os desenvolvedores corporativos, e depois passa para a monetização quando a empresa começa a introduzir contêineres na produção. ”


(Fonte: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863 )

Esperamos que você tenha gostado deste artigo. Nas próximas postagens desta série, examinaremos mais de perto as vantagens do OpenShift em comparação ao Kubernetes em cada uma das categorias discutidas aqui.

All Articles