c3f4dba513
Automatic merge from submit-queue (batch tested with PRs 47416, 47408, 49697, 49860, 50162) add possibility to use multiple floatingip pools in openstack loadbalancer **What this PR does / why we need it**: Currently only one floating pool is supported in kubernetes openstack cloud provider. It is quite big issue for us, because we want run only single kubernetes cluster, but we want that external and internal services can be used. It means that we need possibility to create services with internal and external pools. **Which issue this PR fixes**: fixes #49147 **Special notes for your reviewer**: service labels is not maybe correct place to define this floatingpool id. However, I did not find any better place easily. I do not want start modifying service api structure. **Release note**: ```release-note Add possibility to use multiple floatingip pools in openstack loadbalancer ``` Example how it works: ``` cat /etc/kubernetes/cloud-config [Global] auth-url=https://xxxx username=xxxx password=xxxx region=yyy tenant-id=b23efb65b1d44b5abd561511f40c565d domain-name=foobar [LoadBalancer] lb-version=v2 subnet-id=aed26269-cd01-4d4e-b0d8-9ec726c4c2ba lb-method=ROUND_ROBIN floating-network-id=56e523e7-76cb-477f-80e4-2dc8cf32e3b4 create-monitor=yes monitor-delay=10s monitor-timeout=2000s monitor-max-retries=3 ``` ``` apiVersion: apps/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 template: metadata: labels: run: web spec: containers: - name: nginx image: nginx ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: labels: run: web-ext name: web-ext namespace: default spec: selector: run: web ports: - port: 80 name: https protocol: TCP targetPort: 80 type: LoadBalancer --- apiVersion: v1 kind: Service metadata: labels: run: web-int floatingPool: a2a84887-4915-42bf-aaff-2b76688a4ec7 name: web-int namespace: default spec: selector: run: web ports: - port: 80 name: https protocol: TCP targetPort: 80 type: LoadBalancer ``` ``` % kubectl create -f example.yaml deployment "nginx-deployment" created service "web-ext" created service "web-int" created % kubectl get svc -o wide NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes 10.254.0.1 <none> 443/TCP 2m <none> web-ext 10.254.23.153 192.168.1.57,193.xx.xxx.xxx 80:30151/TCP 52s run=web web-int 10.254.128.141 192.168.1.58,10.222.130.80 80:32431/TCP 52s run=web ``` cc @anguslees @k8s-sig-openstack-feature-requests @dims
Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Cloud Providers in this directory will continue to be actively developed or maintained and supported at their current level of support as a longer-term solution evolves.
Overview:
The mechanism for supporting cloud providers is currently in transition: the original method of implementing cloud provider-specific functionality within the main kubernetes tree (here) is no longer advised; however, the proposed solution is still in development.
Guidance for potential cloud providers:
- Support for cloud providers is currently in a state of flux. Background information on motivation and the proposal for improving is in the github proposal.
- In support of this plan, a new cloud-controller-manager binary was added in 1.6. This was the first of several steps (see the proposal for more information).
- Attempts to contribute new cloud providers or (to a lesser extent) persistent volumes to the core repo will likely meet with some pushback from reviewers/approvers.
- It is understood that this is an unfortunate situation in which 'the old way is no longer supported but the new way is not ready yet', but the initial path is unsustainable, and contributors are encouraged to participate in the implementation of the proposed long-term solution, as there is risk that PRs for new cloud providers here will not be approved.
- Though the fully productized support envisioned in the proposal is still 2 - 3 releases out, the foundational work is underway, and a motivated cloud provider could accomplish the work in a forward-looking way. Contributors are encouraged to assist with the implementation of the design outlined in the proposal.
Some additional context on status / direction:
- 1.6 added a new cloud-controller-manager binary that may be used for testing the new out-of-core cloudprovider flow.
- Setting cloud-provider=external allows for creation of a separate controller-manager binary
- 1.7 adds extensible admission control, further enabling topology customization.