One place for hosting & domains


      How One INAP Customer Is Disrupting Desktop as Service Solutions for the SMB Market

      Remote work demands efficient and always-on desktop as a service (DaaS) solutions that allow employees to work and collaborate at any time, from anywhere, on any device.

      Because an increasing number of businesses are going completely or mostly remote and many others have a mix of full-time remote and in-office workers, providing a seamless and secure experience for employees across the board is no easy feat for IT teams.

      DaaS solutions come from a third-party provider, companies do not have control of the backend infrastructure and must rely on the provider—ideally one with a robust SLA—for reliable and scalable service. Furthermore, traditional DaaS solutions take weeks to set up, with hours of planning and configuring before the client can put it to use.

      To both meet growing demand and address the shortcomings of current remote desktop products, Denis Zhirovetskiy, president and founder of Adeptcore, a managed IT service provider (MSP) and INAP customer, created his own remote DaaS solution packaged for MSPs. In its first year, the product took off, boasting strong adoption and organic growth.

      We sat down with Zhirovetskiy to learn more about Adeptcore, the Adeptcloud service and how the partnership with INAP has helped the company grow and scale from the very beginning.

      Addressing SMB Remote Worker Needs

      Adeptcore was founded with the purpose of helping a small- or medium-sized business (SMB) use their current technology and make it better, setting themselves apart from companies that sell pre-packaged, per-user or per-device plans.

      “We heavily focus on onboarding clients. We can spend three months onboarding one client,” Zhirovetskiy said. “We invest that time because we want to know what each of our clients does for a living and how they’re generating revenue. From there, we tailor the technology to support that mission.”

      In line with this purpose, Adeptcore launched Adeptcloud in June of 2018, after a peer in the MSP community requested to use Zhirovetskiy’s proprietary DaaS solution for a client. The MSP was surprised that Adeptcore was not using industry leaders in the market for DaaS solutions and wanted to see why they created their own. Zhirovetskiy explained that his key selling point was that his solution ran on Nimble SAN with SSD cache, ensuring greater performance and reliability. Other providers typically used spinning disks.

      Zhirovetskiy realized the product would work for MSPs at large. To scale the product, he worked with Ray Orsini, owner of OITVOIP and one of the first Adeptcloud partners. This collaboration ensured that Adeptcloud worked with VoIP softphone technology. As he worked with Orsini, Zhirovetskiy discovered that he was also an INAP customer, and noted that this helped him certify that their products would work together.

      “I started talking with other managed IT providers on an internet forum, and when they saw our solution, they immediately wanted to do something similar for their clients,” he said. “That’s honestly all the marketing I’ve ever done for it.”

      From there, the product took off. During the first 12 months of business, from June 2018 to June 2019, Adeptcloud grew to have 65 partners across the U.S. and three internationally. Adeptcloud has users log on daily from Peru and New Zealand, and has clients working from India, Dubai and China.

      Why Adeptcloud Stands Out

      What exactly helped Adeptcloud take off so quickly? What sets it apart from other DaaS products?

      Saving Time

      First, Adeptcloud saves MSPs time. “We offer a ready-to-go solution in a box. All they have to do is fill out a form and within three days their customers are able to login and begin working. They don’t have to worry about it,” Zhirovetskiy said.

      The Adeptcloud solution has been shown to reduce MSP ticket volumes by as much as 40 percent once the solution is deployed and user training is complete. Zhirovetskiy notes that his team generally goes two to three months without tickets from clients after the first month of implementation.

      Ensuring Unified Threat Management

      Proactive mitigation of ever-evolving security threats is another benefit that sets Adeptcloud apart. They’ve partnered with a number of top security technology companies to develop an environment where customers can store their sensitive client data without a worry of it being lost or encrypted due to a ransomware attack.

      Zhirovetskiy also just added top-of-the-line firewalls and threat management services to his INAP solution, noting that Adeptcore will be the only provider he knows of to offer fully unified threat management functionality to clients.

      “We work with holistic, two-factor authentication security solutions and deploy those solutions for our partners. They don’t have to do any of it. They just tell us what they want and we build it out and release it to them,” Zhirovetskiy said.

      Focusing on End User and Partner Experience

      Ultimately, it is Adeptcore’s focus on the end user that makes Adeptcloud work as a successful cloud solution.

      “Most companies that get into the business offering a cloud service are focusing strictly on the tech itself,” Zhirovetskiy said. “They don’t focus on the end-user support, they don’t focus on the client experience and they don’t focus on supporting their partners. They focus on selling cloud.”

      Partners can get the support they need with Adeptcloud. “When a MSP partner calls our support desk, they talk to someone who is on the same technical level. This is huge for IT companies—they spend less time dealing with the bureaucracy created by huge organizations.”

      Scaling Adeptcloud with INAP

      Zhirovetskiy has been working with INAP since the founding of Adeptcore, when the company started with one client and one server. Adeptcore wanted a data center company located in Chicago, and chose INAP for its security and service reliability.

      “It’s hard to find a global company like INAP that feels like a local company,” he said. “I have a dedicated team and somebody to call who will take care of my needs. That’s the biggest reason I would recommend anybody work with INAP.”

      Throughout the relationship with INAP, Zhirovetskiy has worked with his account manager, Steven Anderson, and INAP engineers to scale the Adeptcloud solution. He says that he talks to Anderson on a weekly basis to discuss the future of his solution: “As our platform has evolved, we always know we have experts available to assist us with our growth.”

      Adeptcore uses INAP engineers for full-spectrum infrastructure solutions, from developing backup services using Veeam to designing Adeptcore’s networking infrastructure. The relationship continues to evolve as Adeptcore grows its cloud footprint and expands to other INAP data centers beyond Chicago.

      “INAP support has been instrumental in helping us achieve our goals. From managing downtime to planning our next big thing,” Zhirovetskiy said. “We rely on INAP to provide us infrastructure expertise, while we provide expertise to our clients on what we’re good at—delivering them their desktops every single day.”

      Explore INAP’s Data Centers.


      Laura Vietmeyer


      Source link

      How to Defeat Ransomware With Disaster Recovery as a Service

      Given the eye-catching headlines and high-profile disasters, ransomware’s ability to wreak havoc probably needs no introduction.

      Case in point: The government of Jackson County, Georgia, was recently forced to pay $400,000 in cryptocurrency to a criminal gang that had taken over the network and encrypted their environment, making it completely unusable. Numerous stories like this can be found in headlines across the globe, taken from the experiences of hospitals, universities and businesses alike.

      In 2017, the FBI’s Internet Crime Complaint Center received 1,783 complaints from U.S. organizations that were infected with ransomware. These attacks cost millions of dollars in losses. Yet these numbers represent only a fraction of the total number of attacks, as the vast majority are never reported to the FBI.

      Certainly, ransomware can be devastating, but here’s a secret: It doesn’t have to be.

      Disaster Recovery as a Service (DRaaS) allows you to invalidate the threat of ransomware by creating redundancy in your environment. This blog will cover how that works, but first, let’s take some time to understand ransomware.

      What Is Ransomware?

      Ransomware comes in many forms, but two main varieties have emerged: locker-ware and crypto-ware. Locker-ware involves a hacker taking control of a specific computer or network and then changing passwords so that systems cannot be accessed. Crypto-ware uses encryption techniques to mask all data, rendering it unreadable or unusable.

      In both types of ransomware attacks, the criminals extort the organization, offering to unlock the system only after receiving payment (usually in the form of cryptocurrency).

      In 2017, ransomware program WannaCry made headlines, infecting an estimated 200,000 computers and netting its creators roughly $300 every time someone chose to pay to decrypt their computers. The real cost, however, is far greater when you include lost productivity and the work required to recover systems impacted by WannaCry. Estimates ranged from hundreds of millions of dollars, even into the billions.

      Disaster Recovery as a Service (DRaaS): The Silver Bullet for Ransomware

      The first line of defense against any cyberattack or phishing attempt is proper security training for all employees. Foundational security measures include training employees to validate links before clicking them and verifying the identity and legitimacy of senders. For example, a common trick of hackers involves replacing or switching letters in email addresses to make them appear legitimate (e.g., vs. Every organization should have strong group policy objects set for their end users, such as enforcing unique passwords, limiting the installation of software and disabling forced system restarts.

      One of the best ways to protect your organization from ransomware is to put in place Disaster Recovery as a Service (DRaaS) for your critical applications and infrastructure. DRaaS comes in different flavors, and which option you go with will depend on your recovery needs: i.e., Recovery Point Objectives and Recovery Time Objectives. Read our blog on RPO and RTO to learn about what these mean.

      Regardless of how often you need to back up (RPO) or how quickly you need your applications to be online (RTO), DRaaS is a straightforward, effective way to neutralize the threat of ransomware.

      Here’s how: DRaaS safeguards your physical and virtual systems by creating a functionally redundant environment that you can switch on in the case of any disaster. This minimizes downtime and its impact on your business, while ensuring that you have a “clean” environment that is safe from any malware—ransomware or otherwise.

      If attackers do gain control of your systems, all you have to do is contact your DRaaS service provider to begin the recovery process. As an INAP customer, you can call, email or log in to your portal to immediately let us know what’s happened. We will work with you to verify what systems or files need to be recovered, confirm the recovery point you need, then begin a full recovery to overwrite the compromised environment. This process will usually follow a detailed runbook that is collaboratively designed when the DRaaS solution was first implemented as part of our white glove onboarding.

      Learn More About INAP Disaster Recovery as a Service

      INAP offers two kinds of Disaster Recovery as a Service: On-Demand DRaaS and Dedicated DRaaS. Both offer redundancy and protection from ransomware—built on our secure, high-performance private cloud. We also offer disaster recovery testing to evaluate your DRaaS solution’s efficacy in a realistic scenario, in addition to a white glove onboarding service.

      With a DRaaS solution in place, you can feel confident that your environments are safe from would-be hijackers and, most importantly, costly downtime—whether caused by ransomware, natural disaster, human error or anything else.

      Explore INAP Disaster Recovery as a Service.


      Allan Williamson
      • Technical Account Manager


      Source link

      Uma Introdução aos Service Meshes


      Um service mesh é uma camada de infraestrutura que permite gerenciar a comunicação entre os microsserviços da sua aplicação. À medida que mais desenvolvedores trabalham com microsserviços, os service meshes evoluíram para tornar esse trabalho mais fácil e mais eficaz consolidando tarefas administrativas e de gerenciamento comuns em uma configuração distribuída.

      Aplicar uma abordagem de microsserviço à arquitetura de aplicações envolve dividir sua aplicação em uma coleção de serviços fracamente acoplados. Essa abordagem oferece certos benefícios: as equipes podem iterar projetos e escalar rapidamente, usando uma variedade maior de ferramentas e linguagens. Por outro lado, os microsserviços representam novos desafios para a complexidade operacional, consistência de dados e segurança.

      Service meshes são projetados para resolver alguns desses desafios, oferecendo um nível granular de controle sobre como os serviços se comunicam uns com os outros. Especificamente, eles oferecem aos desenvolvedores uma maneira de gerenciar:

      • Descoberta de serviço
      • Roteamento e configuração de tráfego
      • Criptografia e autenticação/autorização
      • Métricas e monitoramento

      Embora seja possível executar essas tarefas de forma nativa com orquestradores de containers como o Kubernetes, essa abordagem envolve uma maior quantidade de tomadas de decisão e administração antecipadas quando comparada com o que as soluções de service mesh como o Istio e o Linkerd oferecem por fora. Nesse sentido, service meshes podem agilizar e simplificar o processo de trabalho com componentes comuns em uma arquitetura de microsserviço. Em alguns casos, eles podem até ampliar a funcionalidade desses componentes.

      Por que Service Meshes?

      Service meshes são projetados para resolver alguns dos desafios inerentes às arquiteturas de aplicações distribuídas.

      Essas arquiteturas cresceram a partir do modelo de aplicação de três camadas, que dividia as aplicações em uma camada web, uma camada de aplicação e uma camada de banco de dados. Ao escalar, esse modelo se mostrou desafiador para organizações que experimentam um rápido crescimento. Bases de código de aplicações monolíticas podem se tornar bagunçadas, conhecidas como “big balls of mud”, impondo desafios para o desenvolvimento e o deployment.

      Em resposta a esse problema, organizações como Google, Netflix e Twitter desenvolveram bibliotecas “fat client” internas para padronizar as operações de runtime entre os serviços. Essas bibliotecas forneceram balanceamento de carga, circuit breaker , roteamento e telemetria — precursores para recursos de service mesh. No entanto, eles também impuseram limitações às linguagens que os desenvolvedores poderiam usar e exigiram mudanças nos serviços quando eles próprios foram atualizados ou alterados.

      Um design de microsserviço evita alguns desses problemas. Em vez de ter uma base de código grande e centralizada de aplicações, você tem uma coleção de serviços gerenciados discretamente que representam um recurso da sua aplicação. Os benefícios de uma abordagem de microsserviço incluem:

      • Maior agilidade no desenvolvimento e no deployment, já que as equipes podem trabalhar e fazer deploy de diferentes recursos de aplicações de forma independente.
      • Melhores opções para CI/CD, já que microsserviços individuais podem ser testados e terem deploys refeitos independentemente.
      • Mais opções para linguagens e ferramentas. Os desenvolvedores podem usar as melhores ferramentas para as tarefas em questão, em vez de se restringirem a uma determinada linguagem ou conjunto de ferramentas.
      • Facilidade de escalar.
      • Melhorias no tempo de atividade, experiência do usuário e estabilidade.

      Ao mesmo tempo, os microsserviços também criaram desafios:

      • Sistemas distribuídos exigem diferentes maneiras de pensar sobre latência, roteamento, fluxos de trabalho assíncronos e falhas.
      • As configurações de microsserviço podem não atender necessariamente aos mesmos requisitos de consistência de dados que as configurações monolíticas.
      • Níveis maiores de distribuição exigem designs operacionais mais complexos, particularmente quando se trata de comunicação de serviço a serviço.
      • A distribuição de serviços aumenta a área de superfície para vulnerabilidades de segurança.

      Service meshes são projetados para resolver esses problemas, oferecendo controle coordenado e granular sobre como os serviços se comunicam. Nas seções a seguir, veremos como service meshes facilitam a comunicação de serviço a serviço por meio da descoberta de serviços, roteamento e balanceamento interno de carga, configuração de tráfego, criptografia, autenticação e autorização, métricas e monitoramento. Vamos utilizar a aplicação de exemplo Bookinfo do Istio — quatro microsserviços que juntos exibem informações sobre determinados livros — como um exemplo concreto para ilustrar como os service meshes funcionam.

      Descoberta de Serviço

      Em um framework distribuído, é necessário saber como se conectar aos serviços e saber se eles estão ou não disponíveis. Os locais das instâncias de serviço são atribuídos dinamicamente na rede e as informações sobre eles estão em constante mudança, à medida que os containers são criados e destruídos por meio do escalonamento automático, upgrades e falhas.

      Historicamente, existiram algumas ferramentas para fazer a descoberta de serviços em uma estrutura de microsserviço. Repositórios de chave-valor como o etcd foram emparelhados com outras ferramentas como o Registrator para oferecer soluções de descoberta de serviços. Ferramentas como o Consul iteraram isso combinando um armazenamento de chave-valor com uma interface de DNS que permite aos usuários trabalhar diretamente com seu servidor ou nó DNS.

      Tomando uma abordagem semelhante, o Kubernetes oferece descoberta de serviço baseada em DNS por padrão. Com ele, você pode procurar serviços e portas de serviço e fazer pesquisas inversas de IP usando convenções comuns de nomenclatura de DNS. Em geral, um registro A para um serviço do Kubernetes corresponde a esse padrão: serviço.namespace.svc.cluster.local. Vamos ver como isso funciona no contexto do aplicativo Bookinfo. Se, por exemplo, você quisesse informações sobre o serviço details do aplicativo Bookinfo, poderia ver a entrada relevante no painel do Kubernetes:

      Details Service in Kubernetes Dash

      Isto lhe dará informações relevantes sobre o nome do serviço, namespace e ClusterIP, que você pode usar para se conectar ao seu serviço, mesmo que os containers individuais sejam destruídos e recriados.

      Um service mesh como o Istio também oferece recursos de descoberta de serviço. Para fazer a descoberta de serviços, o Istio confia na comunicação entre a API do Kubernetes, o próprio plano de controle do Istio, gerenciado pelo componente de gerenciamento de tráfego Pilot, e seu plano de dados, gerenciado pelos proxies sidecar Envoy. O Pilot interpreta os dados do servidor da API do Kubernetes para registrar as alterações nos locais do Pod. Em seguida, ele converte esses dados em uma representação canônica Istio e os encaminha para os proxies sidecar.

      Isso significa que a descoberta de serviço no Istio é independente de plataforma, o que podemos ver usando o add-on Grafana do Istio para olhar o serviço details novamente no painel de serviço do Istio:

      Details Service Istio Dash

      Nossa aplicação está sendo executada em um cluster Kubernetes, então, mais uma vez, podemos ver as informações relevantes do DNS sobre o Serviço details, juntamente com outros dados de desempenho.

      Em uma arquitetura distribuída, é importante ter informações atualizadas, precisas e fáceis de localizar sobre serviços. Tanto o Kubernetes quanto os service meshes, como o Istio, oferecem maneiras de obter essas informações usando convenções do DNS.

      Configuração de Roteamento e Tráfego

      Gerenciar o tráfego em uma estrutura distribuída significa controlar como o tráfego chega ao seu cluster e como ele é direcionado aos seus serviços. Quanto mais controle e especificidade você tiver na configuração do tráfego externo e interno, mais você poderá fazer com sua configuração. Por exemplo, nos casos em que você está trabalhando com deployments piloto (canary), migrando aplicativos para novas versões ou testando serviços específicos por meio de injeção de falhas, ter a capacidade de decidir quanto tráfego seus serviços estão obtendo e de onde ele vem será a chave para o sucesso de seus objetivos.

      O Kubernetes oferece diferentes ferramentas, objetos e serviços que permitem aos desenvolvedores controlar o tráfego externo para um cluster: kubectl proxy, NodePort, Load Balancers, e Ingress Controllers and Resources. O kubectl proxy e o NodePort permitem expor rapidamente seus serviços ao tráfego externo: O kubectl proxy cria um servidor proxy que permite acesso ao conteúdo estático com um caminho HTTP, enquanto o NodePort expõe uma porta designada aleatoriamente em cada node. Embora isso ofereça acesso rápido, as desvantagens incluem ter que executar o kubectl como um usuário autenticado, no caso do kubectl proxy, e a falta de flexibilidade nas portas e nos IPs do node, no caso do NodePort. E, embora um Balanceador de Carga otimize a flexibilidade ao se conectar a um serviço específico, cada serviço exige seu próprio Balanceador de Carga, o que pode custar caro.

      Um Ingress Resource e um Ingress Controller juntos oferecem um maior grau de flexibilidade e configuração em relação a essas outras opções. O uso de um Ingress Controller com um Ingress Resource permite rotear o tráfego externo para os serviços e configurar o roteamento interno e o balanceamento de carga. Para usar um Ingress Resource, você precisa configurar seus serviços, o Ingress Controller e o LoadBalancer e o próprio Ingress Resource, que especificará as rotas desejadas para os seus serviços. Atualmente, o Kubernetes suporta seu próprio Controlador Nginx, mas há outras opções que você pode escolher também, gerenciadas pelo Nginx, Kong, e outros.

      O Istio itera no padrão Controlador/Recurso do Kubernetes com Gateways do Istio e VirtualServices. Como um Ingress Controller, um gateway define como o tráfego de entrada deve ser tratado, especificando as portas e os protocolos expostos a serem usados. Ele funciona em conjunto com um VirtualService, que define rotas para serviços dentro da malha ou mesh. Ambos os recursos comunicam informações ao Pilot, que encaminha essas informações para os proxies Envoy. Embora sejam semelhantes ao Ingress Controllers and Resources, os Gateways e os VirtualServices oferecem um nível diferente de controle sobre o tráfego: em vez de combinar camadas e protocolos Open Systems Interconnection (OSI), Gateways e VirtualServices permitem diferenciar entre as camadas OSI nas suas configurações. Por exemplo, usando VirtualServices, as equipes que trabalham com especificações de camada de aplicação podem ter interesses diferenciados das equipes de operações de segurança que trabalham com diferentes especificações de camada. Os VirtualServices possibilitam separar o trabalho em recursos de aplicações distintos ou em diferentes domínios de confiança e podem ser usados para testes como canary, rollouts graduais, testes A/B, etc.

      Para visualizar a relação entre os serviços, você pode usar o add-on Servicegraph do Istio, que produz uma representação dinâmica da relação entre os serviços usando dados de tráfego em tempo real. A aplicação Bookinfo pode se parecer com isso sem qualquer roteamento personalizado aplicado:

      Bookinfo service graph

      Da mesma forma, você pode usar uma ferramenta de visualização como o Weave Scope para ver a relação entre seus serviços em um determinado momento. A aplicação Bookinfo sem roteamento avançado pode ter esta aparência:

      Weave Scope Service Map

      Ao configurar o tráfego de aplicações em uma estrutura distribuída, há várias soluções diferentes — de opções nativas do Kubernetes até service meshes como o Istio — que oferecem várias opções para determinar como o tráfego externo chegará até seus recursos de aplicação e como esses recursos se comunicarão entre si.

      Criptografia e Autenticação/Autorização

      Um framework distribuído apresenta oportunidades para vulnerabilidades de segurança. Em vez de se comunicarem por meio de chamadas internas locais, como aconteceria em uma configuração monolítica, os serviços em uma arquitetura de microsserviço transmitem informações, incluindo informações privilegiadas, pela rede. No geral, isso cria uma área de superfície maior para ataques.

      Proteger os clusters do Kubernetes envolve uma variedade de procedimentos; Vamos nos concentrar em autenticação, autorização e criptografia. O Kubernetes oferece abordagens nativas para cada um deles:

      • Autenticação: As solicitações de API no Kubernetes estão vinculadas a contas de usuário ou serviço, que precisam ser autenticadas. Existem várias maneiras diferentes de gerenciar as credenciais necessárias: Tokens estáticos, tokens de bootstrap, certificados de cliente X509 e ferramentas externas, como o OpenID Connect.
      • Autorização: O Kubernetes possui diferentes módulos de autorização que permitem determinar o acesso com base em funções como papéis, atributos e outras funções especializadas. Como todas as solicitações ao servidor da API são negadas por padrão, cada parte de uma solicitação da API deve ser definida por uma política de autorização.
      • Criptografia: Pode referir-se a qualquer um dos seguintes: conexões entre usuários finais e serviços, dados secretos, terminais no plano de controle do Kubernetes e comunicação entre componentes worker do cluster e componentes master. O Kubernetes tem diferentes soluções para cada um deles:

      A configuração de políticas e protocolos de segurança individuais no Kubernetes requer investimento administrativo. Um service mesh como o Istio pode consolidar algumas dessas atividades.

      O Istio foi projetado para automatizar parte do trabalho de proteção dos serviços. Seu plano de controle inclui vários componentes que lidam com segurança:

      • Citadel: gerencia chaves e certificados.
      • Pilot: supervisiona as políticas de autenticação e nomenclatura e compartilha essas informações com os proxies Envoy.
      • Mixer: gerencia autorização e auditoria.

      Por exemplo, quando você cria um serviço, o Citadel recebe essa informação do kube-apiserver e cria certificados e chaves SPIFFE para este serviço. Em seguida, ele transfere essas informações para Pods e sidecars Envoy para facilitar a comunicação entre os serviços.

      Você também pode implementar alguns recursos de segurança habilitando o TLS mútuo durante a instalação do Istio. Isso inclui identidades de serviço fortes para comunicação interna nos clusters e entre clusters, comunicação segura de serviço para serviço e de usuários para serviço, e um sistema de gerenciamento de chaves capaz de automatizar a criação, a distribuição e a rotação de chaves e certificados.

      Ao iterar em como o Kubernetes lida com autenticação, autorização e criptografia, service meshes como o Istio são capazes de consolidar e estender algumas das melhores práticas recomendadas para a execução de um cluster seguro do Kubernetes.

      Métricas e Monitoramento

      Ambientes distribuídos alteraram os requisitos para métricas e monitoramento. As ferramentas de monitoramento precisam ser adaptativas, respondendo por mudanças frequentes em serviços e endereços de rede, e abrangentes, permitindo a quantidade e o tipo de informações que passam entre os serviços.

      O Kubernetes inclui algumas ferramentas internas de monitoramento por padrão. Esses recursos pertencem ao seu pipeline de métricas de recursos, que garante que o cluster seja executado conforme o esperado. O componente cAdvisor coleta estatísticas de uso de rede, memória e CPU de containers e nodes individuais e passa essas informações para o kubelet; o kubelet, por sua vez, expõe essas informações por meio de uma API REST. O servidor de métricas obtém essas informações da API e as repassa para o kube-aggregator para formatação.

      Você pode estender essas ferramentas internas e monitorar os recursos com uma solução completa de métricas. Usando um serviço como o Prometheus como um agregador de métricas, você pode criar uma solução diretamente em cima do pipeline de métricas de recursos do Kubernetes. O Prometheus integra-se diretamente ao cAdvisor através de seus próprios agentes, localizados nos nodes. Seu principal serviço de agregação coleta e armazena dados dos nodes e os expõe através de painéis e APIs. Opções adicionais de armazenamento e visualização também estão disponíveis se você optar por integrar seu principal serviço de agregação com ferramentas de backend de armazenamento, registro e visualização, como InfluxDB, Grafana, ElasticSearch, Logstash, Kibana, e outros.

      Em um service mesh como o Istio, a estrutura do pipeline completo de métricas faz parte do design da malha. Os sidecars do Envoy operando no nível do Pod comunicam as métricas ao Mixer, que gerencia políticas e telemetria. Além disso, os serviços Prometheus e Grafana estão habilitados por padrão (embora se você estiver instalando o Istio com o Helm você precisará especificar granafa.enabled=true durante a instalação). Como no caso do pipeline completo de métricas, você também pode configurar outros serviços e deployments para opções de registro e visualização.

      Com essas ferramentas de métrica e visualização, você pode acessar informações atuais sobre serviços e cargas de trabalho em um local central. Por exemplo, uma visão global do aplicativo BookInfo pode ter esta aparência no painel Grafana do Istio:

      Bookinfo services from Grafana dash

      Ao replicar a estrutura de um pipeline completo de métricas do Kubernetes e simplificar o acesso a alguns de seus componentes comuns, service meshes como o Istio agilizam o processo de coleta e visualização de dados ao trabalhar com um cluster.


      As arquiteturas de microsserviço são projetadas para tornar o desenvolvimento e o deployment de aplicações mais rápidos e confiáveis. No entanto, um aumento na comunicação entre serviços mudou as práticas recomendadas para determinadas tarefas administrativas. Este artigo discute algumas dessas tarefas, como elas são tratadas em um contexto nativo do Kubernetes e como elas podem ser gerenciadas usando service mesh – nesse caso, o Istio.

      Para obter mais informações sobre alguns dos tópicos do Kubernetes abordados aqui, consulte os seguintes recursos:

      Além disso, os hubs de documentação do Kubernetes e do Istio são ótimos lugares para encontrar informações detalhadas sobre os tópicos discutidos aqui.

      Source link