when I experimented with GCP, I found it weird that cloud-run would not work together with the GLB. That was really a surprise.
Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
41–50 of 58 posts
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#42CLOUD NATIVE DEVOPS RAFT-BASED BLOCKCHAIN-ENABLED MULTI CLOUD RESILIENT CONTAINERIZED MULTI-REGION MULTI-AZ static blog generator.
Oh I’m so sorry, we were expecting “Paxos” for the correct answer. Unfortunately I cannot accept your answer.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#43> This means the Service must be created first, then when the corresponding NEG is created the name can be queried and added to the Terraform project. These kind of reverse dependencies, where app level changes have to be reflected in infrastructure are source of endless bugs and headaches. To do it right, you'd want to encode app and infra changes in the same ubiquitous tool, but "infrastructure as a code" tools suc…
What about the Pulumi solution gets in your way?
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#44Earlier quoted context omitted.
This seems to be a common rhetoric from people who have not invested the time in k8s. It is not as complicated as people think.
I've used k8s at various times since it's inception. I've yet to see a compelling argument for running your control plane on the same layer as your workloads. I have always found this to be a recipe of disaster when 'something' in your service dependency chain breaks. Also not having load balancer support built in kills it for me. Yeah you can do metallb or nginx ingress but it means they punted one of the major comp…
Kubernetes splits the control plane from the workloads. You have to run Kubelet on the individual nodes, but it's in charge of node-local orchestration; sure, you could maybe invent something thinner that was controlled with just with SSH or something, but you can't really get away with some kind of controller on the node itself. Something has to start containers and monitor their status, for one.
There are lots of production-quality load balancer implementations for Kubernetes, such as Traefik, as well as operators that configure cloud-native load balancers (e.g. the one that configures GLBs on GCP). I don't see this as missing functionality. The ingress story isn't great, but the available options (Nginx being a very solid example of something tried and tested) are good enough that it's more a problem of standardization, not implementation.
Neither of those two points seem to sufficiently argue against using Kubernetes. Having used it for a few years now for all sorts of workloads, I would never go back to plain VMs, nor to something like ECS or Mesos. The only alternative I might entertain would be "serverless", but the available offerings don't seem to cover all the bases (e.g. batch jobs).
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#45Is the title peak buzzword-era, or is there more to come?
They are product and feature names used by the GCP platform (and this article). It's perfectly accurate and descriptive.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#46Is the title peak buzzword-era, or is there more to come?
I think that is unfair. Each of those buzz words were concepts in the article or actual products that GCP offers. However, this is embarrassing to GCP that this isn’t easier. These were very basic requirements from this customer, yet so much rigmarole was needed to get it set up.
Multi-cluster global load balancing isn't "very basic" and no other cloud is any easier.
AWS requires stacking the Global Accelerator on top of their ALB/ELBs but doesn't have smart routing across clusters and Azure only has Frontdoor which requires completely manual setup and has no backend integration.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#47Is the title peak buzzword-era, or is there more to come?
I remember when load balancing was a case of setting up apache or nginx on a server and letting it handle the upstream connections.
It still is... if you're just running a few apps on single server, or 1 load balancer VM in front of a few other servers.
This article is talking about routing traffic from a single IP globally to multiple backend Kubernetes clusters that can be running in any region. Traffic will automatically go to the closest region (with available capacity) or otherwise fallback to other endpoints, while also bypassing much of the Kubernetes network stack to go straight to the running pods via GCP's software-defined network.
The complexity here is warranted if you need the flexibility and features. If you don't then you can just stick with nginx.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#48Earlier quoted context omitted.
I think that is unfair. Each of those buzz words were concepts in the article or actual products that GCP offers. However, this is embarrassing to GCP that this isn’t easier. These were very basic requirements from this customer, yet so much rigmarole was needed to get it set up.
Multi-cluster global load balancing isn't "very basic" and no other cloud is any easier. AWS requires stacking the Global Accelerator on top of their ALB/ELBs but doesn't have smart routing across clusters and Azure only has Frontdoor which requires completely manual setup and has no backend integration.
Deploying an app to more than one geographic region on earth should be very basic. For mostly read only sites, it is mean to make your users suffer extra latency and your reliability goes down.
The authors had to go read source code to figure out obscure annotations at one point to get container aware networking to work, which then wasn’t compatible with Google’s tools to setup global ingress.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#49Earlier quoted context omitted.
Multi-cluster global load balancing isn't "very basic" and no other cloud is any easier. AWS requires stacking the Global Accelerator on top of their ALB/ELBs but doesn't have smart routing across clusters and Azure only has Frontdoor which requires completely manual setup and has no backend integration.
Deploying an app to more than one geographic region on earth should be very basic. For mostly read only sites, it is mean to make your users suffer extra latency and your reliability goes down. The authors had to go read source code to figure out obscure annotations at one point to get container aware networking to work, which then wasn’t compatible with Google’s tools to setup global ingress.
That isn't very basic and never has been. If it's just a read-only site then all you need is a CDN, not load balancing with multiple regions running Kubernetes clusters.
What other cloud vendor or PaaS offers this? The only one that has seamless global deployment is Cloudflare's Workers but that's limited to Javascript code in a lightweight functions environment.
Re: Container-Native Multi-Cluster Global Load Balancing with Cloud Armor on GCP
#50> This means the Service must be created first, then when the corresponding NEG is created the name can be queried and added to the Terraform project. These kind of reverse dependencies, where app level changes have to be reflected in infrastructure are source of endless bugs and headaches. To do it right, you'd want to encode app and infra changes in the same ubiquitous tool, but "infrastructure as a code" tools suc…
What about the Pulumi solution gets in your way?
No tools IaC tools I know of including Pulumi, allow to describe evolutions for infra. Simple use case - deploy canary instance, check it's health, scale down canary instance, update main pool of instances.
In other words, there is no way to express sequence of changes of the same object in the single run of IaC tool. We are forced to wrap IaC tools in layers of bash to simulate it.