So, now that the Kubernetes based rack has launched, and the documentation is live
It contains no mention of AWS Fargate anymore. Has support for AWS Fargate been dropped? Is it something that has just not yet been added back in since the priority was on the multi-cloud features not the more advanced features of individual clouds?
While abstracting away complexity is why I use Convox in the first place, the new documentation seems to go out of its way to avoid mentioning what underlying mechanisms power things, like the primitives section… making it harder to reason about what is going to happen in a production environment by leveraging the extant body of knowledge available online with regards to how Kubernetes operates in practice. I cant even tell from the documentation if Convox deploys a Kubernetes environment on AWS using the managed Kubernetes service (AKE) or if Convox builds the entire Kubernetes environment. Is my Database going to be some ephemeral container or on RDS?
The documentation mentions pods only in in the log output of other commands. A pod is one of Kubernetes most basic primitives, at some point in the future are we going to get a mechanism for saying that a service is composed of multiple containers/processes deployed together as a single pod? Sidecars like this are a significant tool used by a lot of things in the Kubernetes ecosystem, so lacking support for them is a significant limitation.
Hi @sam,
Thanks for the questions! I’ll try and answer as best I can
Fargate support in EKS is still new in general, so we don’t support it yet but we likely will. It is still supported on the ECS Racks.
We do utilise the Kubernetes services of each cloud we support so far, so yes, on AWS we use EKS, on GCP we use GKE etc… Resources specified in your convox.yml such as Databases would be created and run in containers on the new Racks. This allows for greater parity across all environments. Coming soon will be the ability to easily run these in RDS (for AWS), CloudSQL (for GCP), SQL Database (for Azure) etc…
Sidecars aren’t in there yet but we’re actively thinking about how best to support them.
Yes! With the changes we’ve made/our making we’re actually making it easier to manage multiple Racks without ever having to touch the Convox console if that’s what you wish!
We’re about to publish an easy migration guide, which shows you how to export/import your entire app between Racks with a couple of CLI commands.
Or, put differently, where do we go to find request metrics on the k8s cluster?
For instances, I’m looking for the stats I’m normally go to the monitoring tab of an ELB to show me. When I look a the ELB that’s pointing to the k8s cluster, the requests don’t seem to correspond to any traffic that I’m throwing at it (I’m assuming this is because the ELB is in TCP mode, but maybe I’m doing something wrong?)
Any update on the migration guide from v2 racks? We need to up9date our infrastructure to have a static IP, and I’m debating between converting my existing v2 racks to “internal” vs upgrading to V3.
Nothing in that upgrade guide discusses how to maintain your static IP addresses. And the rest of the documentation is unclear on that, too.
There IS mention of static IP addresses if you allocate a load balancer, but trying that and running convox balancers the resulting endpoint is a DNS address, not an IP address.
