Unless you’re living under a monolithic rock, you know that Kubernetes has become the platform of choice for building microservices-based apps. Kubernetes enables you to automatically deploy, scale, and manage containerized apps on hybrid and multi-cloud environments. According to a recent Cloud Native Computing Foundation survey, nearly 40 percent of respondents are running Kubernetes in production. One of their top challenges: networking.
In this series of blog posts, we will discuss the challenges that you may encounter when moving toward Kubernetes-based applications and how Citrix ADC can solve them. Let’s start by looking at the Kubernetes networking challenges that users face and that we’ll explore in future posts.
Existing Citrix ADC Users or Kubernetes Admins
What happens to your existing hardware/virtualized ADCs if you start deploying Kubernetes clusters? Can you protect this investment? Citrix Ingress Controller solves this problem by automating your existing Citrix ADC (MPX, SDX, or VPX) with a Kubernetes cluster.
You’ll need to manage and route both north-south and east-west traffic through layer 7 traffic management policies. You’ll also want to apply organization-wide traffic management policies. Ingress Controllers and native kubeproxy do not have several production grade L7 traffic management features. For this, you need to use the Citrix ADC Custom Resource Definitions (CRD) to apply rewrite/responder and similar policies. In an upcoming blog, we’ll detail the benefits of using Citrix Ingress Controller.
App developers will want to expose HTTP/HTTPS/TCP/UDP-based services to end users. The key challenge is the lack of a standard solution that works seamlessly across multiple clouds or on-premises data centers. Our production-grade Ingress solution covers most of app developers’ Ingress needs.
Secondly, developers face many challenges when they have to migrate from a monolithic to microservices architecture and unlock the benefits of the Kubernetes platform. We often hear from customers that they aspire to a service-mesh architecture but aren’t ready for it. In an upcoming blog, we’ll detail a few simple architectures with Citrix ADC CPX and CIC that will serve as your initial steps in this journey.
Site Reliability Engineers (SREs)
SREs want to measure metrics like latency, traffic, errors, saturation (the four golden signals) for Ingress traffic and communication between microservices. Many SREs prefer to use a single tool to look at these metrics and others, including measures related to storage, compute, and more. In an upcoming blog, we will show you how Citrix ADC exports key network performance metrics to popular CNCF tools like Prometheus, Grafana, and EFK stack (Elasticsearch, Fluentd, Kibana).
Microservices troubleshooting and visibility can also be a pain point for SREs if the service level agreement (SLA) for microservices is not met. Because one end-user request can spawn several requests and responses, it can become difficult to pinpoint exactly where the bottleneck is. We will detail how Citrix ADM’s service graph helps with visualizing and debugging the health of microservices in a user-friendly manner.
Canary deployments tools in Kubernetes ecosystem only look into feature correctness of new releases. What if your new release has an impact on network performance, adversely affecting CPU, memory, and HTTP errors? There’s no way to measure this in popular CICD tools such as Spinnaker. In an upcoming blog, we’ll show you how Citrix ADC makes these tools smarter by incorporating key performance metrics.
Any organization’s journey toward microservices architecture and Kubernetes requires solving challenges for a variety of stakeholders. With Citrix ADC, we are striving to help address these challenges through close integration with open source and popular cloud-native ecosystem technologies.
Keep an eye out for our future posts in our Citrix ADC for Kubernetes series, where we’ll help you find the right solutions to your most pressing challenges.