CDK Distribution Does Not Have Redundant Load Balancer
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Kubernetes API Load Balancer |
Fix Released
|
High
|
Cory Johns | ||
Openstack Integrator Charm |
Fix Released
|
High
|
Cory Johns |
Bug Description
CDK deployment consists of 1 Nginx LB that has 3 Masters underneath it. Which means that this single LB is a SPOF.
A possible solution here would be to use haproxy with 3 Nginx LB and therefore solve the issue, like it's documented in the HAproxy page:
https:/
From that page, when configuring the service, the floating IPs have to be defined in the configuration:
juju config kubeapi-
We should have a way to control the IP assignment process. A way to ask OpenStack to just give an IP to be used as the floating ip for the VIP.
The possible solution would be would be to create a subordinate charm that creates a new Octavia LB per cluster/application adds a listener a pool and registers each unit of the application as a member.
Changed in charm-kubeapi-load-balancer: | |
assignee: | nobody → Cory Johns (johnsca) |
status: | Triaged → In Progress |
Changed in charm-kubeapi-load-balancer: | |
importance: | Undecided → Wishlist |
milestone: | none → 1.16 |
Changed in charm-kubeapi-load-balancer: | |
status: | In Progress → Fix Committed |
Changed in charm-kubeapi-load-balancer: | |
status: | Fix Committed → Fix Released |
Changed in charm-openstack-integrator: | |
assignee: | nobody → Cory Johns (johnsca) |
Changed in charm-kubeapi-load-balancer: | |
milestone: | 1.16+ck2 → 1.16+ck3 |
Changed in charm-openstack-integrator: | |
milestone: | 1.16+ck2 → 1.16+ck3 |
Changed in charm-openstack-integrator: | |
status: | In Progress → Fix Released |
Changed in charm-kubeapi-load-balancer: | |
status: | In Progress → Fix Released |
Changed in charm-kubeapi-load-balancer: | |
milestone: | 1.16+ck3 → 1.16+ck2 |
Changed in charm-openstack-integrator: | |
milestone: | 1.16+ck3 → 1.16+ck2 |
Proposal for how we could solve this:
1. Add a new relation to the openstack- integrator charm that looks like this:
provides:
loadbalancer:
interface: public-address
(Notice that this matches the loadbalancer relation provided by the kubeapi- load-balancer. )
2. Deploy CDK without the kubeapi- load-balancer, and instead relate the masters to the new loadbalancer relation on the openstack- integrator.
3. In the openstack- integrator, add handler code for the loadbalancer relation that will create a new Octavia LB that will balance across the k8s masters.
Is this an acceptable approach?