Implement challenge Kubernetes resource deployment #41
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
This should be a subdomain, not the full domain. Signed-off-by: Robert Detjens <github@detjens.dev>
Localhost in the k3d containers is not the host localhost, so it cant pull images from the test registry. Instead, add the registry container to the k3d network and alias the registry name to pull directly. Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
HTTP challenges should work now, but TCP challenges still need some work to update the ingress config in order to get exposed. Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
Signed-off-by: Robert Detjens <github@detjens.dev>
This waits for: - pods to become running - deployments to complete rollouts - ingresses to become published by controller - LoadBalancer services to get external IP Other types of resources or services are ignored and immediately return Ok. Signed-off-by: Robert Detjens <github@detjens.dev>
We don't need to actually create records (nor is there a way to), but this will still log the records it would have created. Signed-off-by: Robert Detjens <github@detjens.dev>
These were added to test overriding the minijinja `default` None handling. Gating in the template was easier, and so this is not needed now. Signed-off-by: Robert Detjens <github@detjens.dev>
detjensrobert
force-pushed
the
dr/deploy-kubernetes
branch
from
1dd5dd2 to
7d44318
Compare
These were contributed to the upstream kube library, so bump it and use those contributed conditions instead of the custom inline ones. Signed-off-by: Robert Detjens <github@detjens.dev>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The meat and potatoes, finally.
Depends on #38.
This deploys all the needed Kubernetes resources for challenges. Each challenge is created in its own namespace, with its
Deployments for all the pods defined in the challenge config, and any exposed services viaServiceLoadBalancers orIngressconfigs.Currently, non-HTTP challenges are exposed via their own separate LoadBalancer service at a DNS domain based on the challenge name. This approach does have a slightly higher cost, since this creates more cloud provider loadbalancers (on AWS each LB is about $20/month). We are also not currently exposing what domain to expose TCP challenges at, so this the name is generated from the challenge name.
This is slightly different than how the configuration was initially designed, where all TCP challenges would be exposed on the same domain at different ports. Doable, but using separate load balancers does not require messing with the ingress controller values to proxy TCP services.
Switching from either of these to the Gateway API would let us keep a single loadbalancer (the Gateway controller) and direct TCP traffic via native ingress-like resources, at whatever domains we want, though each TCP service would still need to be on a different port.