undefined | Better HN

0 pointsraffraffraff4y ago0 comments

Another real-world example I've used that doesn't even require you to have multi-cloud: deploying an EKS cluster to AWS, deploying charts to EKS and finally creating a CNAME to the ALB in Cloudflare. You could even add Cloudflare Access, Workers etc.

0 comments

oneplane4y ago

I'm doing the same thing. First a repo is setup in GitHub using the GitHub provider, when that is done, the base configuration for Flux is added in there and then the lifecycle on that is going to ignore future changes.

Next, an AWS account is generated and then a CIDR is read from Netbox. That is used to create the VPC and subnets, and after that an EKS cluster is created. Next the Kubernetes provider is used to install everything needed for Flux, and it is pointed to the GitHub repo that was setup earlier.

At this point the team that wanted a dedicated Kubernetes cluster can just put their charts and manifests in the github repo and it is automatically deployed.

cconstantine4y ago

I'd still call that multi-cloud ;)

I've done something similar in the real world. We used cloudflare for our dns / application firewall, but we kept a route53 zone mirrored after cloudflare had a spat of issues. It would have let us switch our dns provider as quickly as dns would allow if we had to drop cloudflare.

j / k navigate · click thread line to collapse

0 comments

oneplane4y ago

At this point the team that wanted a dedicated Kubernetes cluster can just put their charts and manifests in the github repo and it is automatically deployed.

cconstantine4y ago

I'd still call that multi-cloud ;)

j / k navigate · click thread line to collapse