Eu e o pessoal da Datawire voltamos recentemente das incríveis conferências KubeCon e CloudNativeCon em Barcelona. Participamos de 6 apresentações no KubeCon, distribuímos um monte de camisetas legais (sem falsa modéstia) em nosso estande, conversamos com dezenas de pessoas e assistimos a apresentações legais. Havia tantas coisas interessantes no KubeCon EU que decidi escrever um post com os principais resultados.
E aqui estão as conclusões que tirei (não em ordem de importância):
- A plataforma cruzada e a nuvem híbrida (ainda) são populares.
- A integração da tecnologia está ganhando força.
- Anúncio SMI (Service Mesh Interface): Fique atento.
- (Nebuloso?) O futuro do Istio.
- Política como código sobe a pilha.
- O Cloud DevEx ainda não está isento de problemas.
- Empresas (ainda) nos estágios iniciais de adoção de tecnologia.
- Kubernetes locais é real (mas cativante).
- Considere clusters um rebanho.
- O sucesso do Kubernetes ainda depende da comunidade.
Houve várias apresentações na conferência sobre várias nuvens (e questões relacionadas: rede e segurança ), mas notei que muitos slides introdutórios nos relatórios do usuário final descreviam infraestrutura ou arquitetura com pelo menos dois provedores de nuvem. No estande da Datawire, falamos sobre tendências de transição para várias nuvens com mais frequência do que em conferências anteriores.
O sucesso do Kubernetes simplificou bastante sua estratégia de várias nuvens, fornecendo excelente abstração para entregas e orquestração. Nos últimos dois anos, a funcionalidade e as APIs do Kubernetes tornaram-se muito mais estáveis, e muitos fornecedores usam essa plataforma. Os recursos de gerenciamento de armazenamento e a conectividade da rede foram aprimorados e existem bons produtos e soluções comerciais de código aberto nessa área. Em sua palestra “Desmistificando o mito: Kubernetes é difícil de organizar o armazenamento”, Saad Ali, desenvolvedor sênior do Google, falou sobre instalações de armazenamento de uma maneira interessante, e Eran Yanay, da Twistlock, apresentou uma boa visão geral das conexões nas “Conexões em Kubernetes: como escrever um plugin CNI do zero . "
Gostei especialmente das várias conversas sobre a combinação do Azure com as infra-estruturas locais existentes. Recentemente, escrevi um artigo no InfoQ sobre como a arquitetura multiplataforma se relaciona ao trabalho em atualizações de aplicativos . Falei sobre três abordagens: expandir a nuvem para um data center, como no Azure Stack , no AWS Outposts e no GCP Anthos ; garantir uniformidade da estrutura de suprimentos (orquestração) entre vários fornecedores ou nuvens usando uma plataforma como o Kubernetes; garantir a uniformidade da estrutura dos serviços (rede) usando um gateway de API e malha de serviço, como Embaixador e Cônsul .
Nós da Datawire estamos trabalhando duro em gateways de API e, obviamente, estamos inclinados a uma terceira abordagem flexível. Isso permite migrar gradualmente e com segurança de uma pilha tradicional mais próxima da nuvem. HashiCorp e Nick Jackson e eu conversamos na KubeCon com uma palestra sobre "Garantindo a conectividade em nuvem do usuário final ao serviço" .
Tecnologia combina ganho de impulso
Muitos fornecedores oferecem pacotes com ferramentas Kubernetes e tecnologias adicionais. Chamei a atenção para o anúncio do Rio MicroPaaS da Rancher Labs - recentemente eles estão produzindo coisas interessantes. Escrevi no InfoQ um comentário sobre o Submariner , que conecta vários clusters, e os k3s de distribuição leve do Kubernetes . E estou ansioso para aprender o Kubernetes Toolkit da Supergiant . Este é um "conjunto de utilitários para automatizar o fornecimento e o gerenciamento de clusters Kubernetes na nuvem".
Em um ambiente corporativo, os pacotes são direcionados ao armazenamento. Um bom exemplo é o VMware Velero 1.0 (baseado nos desenvolvimentos comprados da Heptio ), com os quais os desenvolvedores podem reservar e migrar recursos do Kubernetes e volumes persistentes.
Muitos outros operadores para armazenar e gerenciar dados no Kubernetes, como CockroachDB , ElasticCloud e StorageOS , estiveram representados na conferência . Red Hat Rob Szumski, da Red Hat, falou sobre a evolução do Operator SDK e da comunidade e apresentou o Operator Hub . Aparentemente, o suporte ao operador é um dos principais benefícios do pacote empresarial OpenShift da Red Hat .
Anúncio SMI (Service Mesh Interface): fique atento
O anúncio do Service Mesh Interface (SMI) em um relatório de Gabe Monroy da Microsoft definitivamente fez muito barulho . Ninguém negará que a malha de serviço tenha sido muito popular ultimamente, e a SMI combinará os principais recursos em uma interface padrão e fornecerá "um conjunto de APIs portáteis comuns que garantirão a interoperabilidade entre diferentes tecnologias de malha de serviço, incluindo Istio, Linkerd e Consul Connect".
Na demonstração, Gabe mostra os principais recursos: política de tráfego para aplicar políticas como credenciais e criptografia de trânsito entre serviços (usando Consul e Intention como exemplo); monitoramento de tráfego - coletando as principais métricas, por exemplo, o número de erros e atrasos na troca de dados entre serviços (usando o Linkerd e o servidor de métricas SMI como exemplo); e gerenciamento de tráfego - medindo e transferindo tráfego entre diferentes serviços (por exemplo, Istio com o Weaveworks Flagger).
Seria interessante definir uma interface nesse ambiente altamente competitivo, mas fui ao site da SMI , li as especificações e suspeito que essa abstração pode ser reduzida a um conjunto mínimo de funções comuns (isso é sempre difícil de evitar em soluções que conheço do meu jeito) Experiência em processos da comunidade Java). O perigo potencial é que, embora todos apliquem essa especificação, os fornecedores fornecerão os recursos mais interessantes por meio de extensões personalizadas.
Conversei sobre isso com o pessoal da Datawire e acho que a malha de serviços existe em um mercado que funciona com o princípio de "o vencedor recebe tudo"; assim, no final, o SMI desviará alguma atenção e outra tecnologia simplesmente aparecerá e coletará todos os benefícios ( algo como Kubernetes fez com Mesos, Docker Swarm, etc.). Acompanhe as notícias, veja o que acontece.
(Hazy?) O futuro de Istio
Embora tenha sido dito muito sobre a malha de serviço, o tema do Istio - talvez a malha de serviço mais famosa - foi misturado. Alguém acredita que Istio e a malha de serviço são sinônimos (como Docker e contêineres) e veem apenas uma solução, não problemas; Alguém gosta dos recursos do Istio; e alguém não está particularmente satisfeito com esta tecnologia.
Houve muita discussão sobre o benchmarking do Istio recentemente e, na Versão 1.1, alguns problemas com o componente Mixer foram deliberadamente resolvidos . Curiosamente, conversei com pessoas diferentes que avaliaram o Istio por vários meses (uma equipe passou quase um ano nisso) e afirmam que o Istio ainda é muito complexo e consome muitos recursos. Alguém diz que a emissão de Istio hospedado por meio do GKE resolveu muitos problemas, mas nem todos podem usar o GCP.
Perguntou a um representante do Google o que aconteceria com Istio, se ele se tornaria um projeto CNCF. A resposta foi muito suave, mas vaga: o Istio agora tem código-fonte aberto, as pessoas podem trabalhar nele e sobre o CNCF, esperar e ver. Até o momento, apenas o Linkerd é o projeto de malha de serviço oficial no CNCF, embora o Envoy Proxy também seja um projeto do CNCF (e o Istio, o gateway da API do Embaixador e muitas outras tecnologias se baseiam nele). No nosso estande, muitos perguntaram sobre a integração do Linkerd 2 e do Ambassador (graças a Oliver Gould, diretor técnico da Buoyant, que mencionou o Ambassador em sua revisão detalhada do Linkerd ), e os participantes gostaram da facilidade de uso do Linkerd.
A propósito, fiquei encantado quando os caras da Knative em seu discurso “Estendendo a Knative para Diversão e Lucro” mostraram que substituíram Istio por Embaixador na Knative, porque o Embaixador é mais fácil de usar (preste atenção nas camisetas na foto e leia a tarefa correspondente no GitHub: “Removendo o Istio como uma dependência” ):
Política como o código sobe a pilha
Em nosso setor, todos já estão acostumados a apresentar a política como código em conexão com um sistema de gerenciamento de identidade e acesso (IAM), configuração de iptable, ACLs e grupos de segurança, mas até agora isso foi feito em um nível baixo, próximo à infraestrutura. Quando ouvi os funcionários da Netflix falarem sobre o uso do Open Policy Agent (OPA) na KubeCon em Austin em 2017 , fiquei imaginando como usar esse projeto para definir uma política como código.
Neste KubeCon, vi que a política à medida que o código aumenta, e mais e mais pessoas discutem o uso da OPA, por exemplo, durante uma palestra de Rita Zhang e Max Smythe , e mais sobre o relatório "Configurações de teste da unidade Kubernetes" usando o Open Policy Agent » Gareth Rushgrove (ele gosta de projetos com grande potencial).
Eu tenho seguido as políticas de definição do HashiCorp Sentinel no nível da infraestrutura e agora, usando o Intention na malha de serviços da Consul, essa tecnologia é ainda mais alta. Com Intenção, uma política pode ser definida no nível do serviço. Por exemplo, o serviço A pode se comunicar com o serviço B, mas não com o serviço C. Quando a equipe da Datawire começou a trabalhar com a HashiCorp para integrar o Embaixador e o Consul, percebemos rapidamente os benefícios de combinar o Intention com mTLS (para identificar serviços) e ACLs (para evitar falsificações e para proteção em vários níveis).
O Cloud DevEx ainda não consegue
Durante a observação final, “Don't Stop Believing”, Bryan Liles, desenvolvedor sênior da VMware, falou sobre a importância do fluxo de trabalho do desenvolvedor (experiência do desenvolvedor, DevEx), e esse tópico foi levantado em várias palestras. O Kubernetes e seu ecossistema estão se desenvolvendo bem, mas o ciclo de desenvolvimento interno e a integração dos oleodutos com o Kubernetes precisam definitivamente de melhorias.
Christian Roggia falou sobre isso em seu relatório "Desenvolvimento Reprodutível e Entrega com Bazel e Telepresença" . Ele falou sobre como Engel e Volkers usam a ferramenta de telepresença CNCF em seu ciclo de desenvolvimento interno para que eles não precisem coletar e enviar o contêiner após cada alteração.
Houve uma discussão em grupo interessante com os funcionários da Weaveworks e Cloudbees, "GitOps e práticas recomendadas para CI / CD na nuvem", que analisou a entrega contínua em detalhes. O GitOps está se desenvolvendo com bastante sucesso; portanto, ao trabalhar no Datawire e em conferências, muitas vezes encontro equipes que usam essa abordagem para configuração e entrega. Por exemplo, Jonathan e Rodrigo mencionaram isso em seu fascinante relatório, “Escalando operações de ponta no Onefootball com o embaixador: 0 a 6.000 solicitações por segundo” :
Empresas (ainda) nos estágios iniciais de adoção de tecnologia
Este é o primeiro KubeCon, em que no estande da Datawire conversei bastante com desenvolvedores de grandes empresas que estão apenas começando a aprender a tecnologia em nuvem. Quase todo mundo já ouviu falar ou experimentou o Kubernetes, mas muitos ainda estão pensando em como integrar sua antiga tecnologia ao novo mundo.
Cheryl Hung, diretora de ecossistemas da CNCF, realizou várias discussões, incluindo “Transformando a empresa com a nuvem”, e foi interessante ouvir pioneiros como a Intuit. Laura Rehorst, em sua palestra “De COBOL a Kubernetes: uma jornada na nuvem para um banco de 250 anos” , descreveu como o ABN AMRO aplicou recursos de planejamento e estratégicos.
Colocamos o gateway da API do embaixador no centro do estande, para que muitas vezes nos perguntassem como o gateway moderno do Kubernetes difere das soluções existentes para gerenciar o ciclo de vida completo da API. Agora, estamos trabalhando no próximo produto comercial nessa área - o Código do Embaixador , e foi interessante discutir com os desenvolvedores os requisitos e expectativas em conexão com os novos paradigmas da nuvem.
Kubernetes local é real (mas cativante)
Houve vários anúncios sobre a instalação local do Kubernetes, especialmente em um ambiente corporativo, por exemplo, Integração do Kublr VMware e VMware e kubeadm . A Red Hat participou de todas as discussões sobre o OpenShift, e ouvi mais de uma vez como as pessoas gostam de abstrações do OpenShift, e a dependência potencial é compensada pelo fluxo de trabalho aprimorado e pelas convenções de SLA que acompanham.
Mas todos repetiram a mesma coisa: você não precisa instalar e manter o Kubernetes, se isso não for absolutamente necessário. E mesmo se você acha que sua empresa é especial, não se apresse: quase todas as empresas que podem usar uma nuvem pública podem usar o Kubernetes como um serviço.
Considere o rebanho de clusters
Em seu interessante relatório, "Como o Spotify excluiu acidentalmente todos os clusters do Kube e os usuários não perceberam nada", David Xia, desenvolvedor do Spotify, contou o que aprenderam quando excluíram vários (!) Clusters de trabalho. Não vou descrever toda a situação (assista ao vídeo), mas a principal mensagem de David foi tratar os clusters Kubernetes como um rebanho. Acho que muitos de nós já ouvimos essa frase: "Trate os servidores como um rebanho, não seus animais de estimação favoritos". Mas David acredita que, com o desenvolvimento da abstração computacional (quando percebemos o "Data Center como um computador" ), devemos aplicar o mesmo princípio e não ficar muito apegados à nossa infraestrutura.
Em sua palestra, O Co-Desenvolvimento de Redes Kubernetes e GCP , Purvi Desai e Tim Hockin, convida organizações a destruir, recriar e migrar permanentemente clusters Kubernetes para não se relacionar com eles. O argumento principal: se você não verificar constantemente a capacidade de restaurar clusters e transferir dados, poderá não ter êxito quando surgir um problema. Imagine que isso é engenharia de caos para clusters.
O sucesso do Kubernetes ainda depende da comunidade.
Nos relatórios, no almoço e no final, um dos tópicos principais era a importância da comunidade e da diversidade. Na manhã de quinta-feira, Lucas Käldström e Nikhita Raghunath, em seu relatório “Primeiros Passos na Comunidade Kubernetes”, não apenas contaram duas histórias incríveis, mas também quebraram todas as desculpas daqueles que não estão envolvidos em projetos de código aberto e projetos CNCF. .
Cheryl Hung, em seu relatório de 2,66 milhões, agradeceu sua enorme contribuição ao projeto e defendeu a diversidade e a liderança. Fiquei surpreso quando soube que mais de 300 bolsas de apoio à diversidade foram financiadas por doações de várias organizações da CNCF.
Conclusão da KubeCon UE
Mais uma vez obrigado a todos com quem conversamos em Barcelona. Se você não pôde participar de nossas apresentações, apresentarei uma lista completa:
Na Datawire, seguimos essas tendências para garantir que o Ambassador continue evoluindo e atendendo às novas necessidades dos desenvolvedores de nuvem. Se você não usou o Ambassador recentemente, experimente nossa versão mais recente - o Ambassador 0.70 com suporte de malha de serviço Consul integrado, suporte personalizado à definição de recursos e muitos outros recursos.
Se você tiver problemas para atualizar, crie uma tarefa ou encontre-nos no Slack . Se você precisar de uma instalação pronta do Ambassador com autenticação integrada, limitação de velocidade e suporte, experimente o nosso produto comercial Ambassador Pro .
E se você gosta de trabalhar com o Embaixador, conte-nos. Deixe um comentário no artigo ou poste @getambassadorio no Twitter.