11–20 of 58 posts
Is 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.
We use terraform end to end and tried the http/https L7 loadbalancer first in our setup but I had a heck of a time with:
- there is no API for the annotation mentioned in the article so if you miss it while setting up a backend, nothing works - gRPC was hard to get going. Most gRPC examples out there use some port such as 50051 so you assume that is needed. gRPC does work over 443.
We currently use istios ingressgateway as a loadbalancer that you set in your kubernetes setup. It works but I don't know if it is better or not. We had to run an ingressgateway pod as a daemonset on every node so that we could get the real IP addresses from requests for security logging. That was a pain.
CLOUD NATIVE DEVOPS RAFT-BASED BLOCKCHAIN-ENABLED MULTI CLOUD RESILIENT CONTAINERIZED MULTI-REGION MULTI-AZ static blog generator.
> 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…
The only and most frustrating missing piece of the terraform kubernetes provider is CRDs. I hacked around it by using some yaml provider bit I would like a cleaner solution.
CLOUD NATIVE DEVOPS RAFT-BASED BLOCKCHAIN-ENABLED MULTI CLOUD RESILIENT CONTAINERIZED MULTI-REGION MULTI-AZ static blog generator.
> 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…
We use terraform for our kubernetes app configuration and it works well. Being able to pass values from one resource to another is extremely powerful. For example, the database instance credentials down into cloudsql proxy. The only and most frustrating missing piece of the terraform kubernetes provider is CRDs. I hacked around it by using some yaml provider bit I would like a cleaner solution.
CLOUD NATIVE DEVOPS RAFT-BASED BLOCKCHAIN-ENABLED MULTI CLOUD RESILIENT CONTAINERIZED MULTI-REGION MULTI-AZ static blog generator.
I downvoted this because even though I like it, it belongs at the bottom of the conversation below any real discussion of the actual article.