Skip to content
This repository has been archived by the owner on Aug 19, 2020. It is now read-only.

Extended configMap #80

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mshaverdo
Copy link
Contributor

@mshaverdo mshaverdo commented Jan 22, 2019

In our usecase we met several problems:

  1. we have several services on the same IP, but it is impossible to specify them in the keepalived-vip configmap due to CM key is justs IP
  2. services defined on several different interfaces, so we need to run several instances of keepalived-vip, one per interface

To solve this problems, we've extended configmap semantics: configmap key now is [OPTIONAL_INDEX-]IP_ADDRESS[@OPTIONAL_INTERFACE], e.g.: 01-10.0.0.1@eth0 or 01-10.0.0.1 or 10.0.0.1@eth0 or just 10.0.0.1. It allows to specify several services on single IPs and explicitly specify interface name. If interface is not specified in configmap, it uses interface specified via --iface flag

It fixes #12 and fixes #77

* implement interface specification for service
* implement multiple services on the same IP
* configmap key now is [OPTIONAL_INDEX-]IP_ADDRESS[@OPTIONAL_INTERFACE]
@CLAassistant
Copy link

CLAassistant commented Jan 22, 2019

CLA assistant check
All committers have signed the CLA.

@coveralls
Copy link

Coverage Status

Coverage increased (+9.2%) to 24.254% when pulling 718a65d on mshaverdo:extended_configmap into f3b9e29 on aledbf:master.

@steven-sheehy
Copy link
Contributor

Can you mark this as fixes #12 and fixes #77?

I'm not a fan of the new format, but it is at least backwards compatible. If we break backwards compatibility we can redesign it as a list instead of map. Let's see what @aledbf thinks.

@aledbf
Copy link
Owner

aledbf commented Jan 23, 2019

@mshaverdo @steven-sheehy I don't like the new format. Right now, using a configmap makes no sense with all the features we are trying to define in a key-value string definition. I think is time to evolve using a no namespaced CRD

@mshaverdo
Copy link
Contributor Author

@steven-sheehy
Copy link
Contributor

Maybe IPv6 support #64?

Looks like multiple nics will also fix #73.

@panpan0000
Copy link
Contributor

panpan0000 commented Apr 10, 2019

@mshaverdo @steven-sheehy I don't like the new format. Right now, using a configmap makes no sense with all the features we are trying to define in a key-value string definition. I think is time to evolve using a no namespaced CRD

👍 concur on CRD
I met the same situation. external IP is quite valuable, reuse the same external IP in NAT mode, map different backend service to different host port is a tradeoff.

@panpan0000
Copy link
Contributor

panpan0000 commented May 27, 2019

another major comment for this implementation:
image there's two lines in the configMap, one says using "interface:eth0", another says "interface:eth1".

But interface is a property of vrrp_instance . There's single vrrp_instance(named vips ) generated in the /etc/keepalived/keepalived.conf. For different items in the configMap, each item will have their own virtual_server, but belongs to the same vrrp_instance .
So in above case, I believe the eth1 will override the eth0 line in configMap.( I did not try )

so I think the resolution for diff NIC interface is : a global config item in CRD...

@panpan0000
Copy link
Contributor

another major comment for this implementation:
image there's two lines in the configMap, one says using "interface:eth0", another says "interface:eth1".

But interface is a property of vrrp_instance . There's single vrrp_instance(named vips ) generated in the /etc/keepalived/keepalived.conf. For different items in the configMap, each item will have their own virtual_server, but belongs to the same vrrp_instance .
So in above case, I believe the eth1 will override the eth0 line in configMap.( I did not try )

so I think the resolution for diff NIC interface is : a global config item in CRD...

forgive my ignorance. iface can be VIP granularity .

  virtual_ipaddress {
    1.2.3.4 dev ens192
    1.2.3.5 dev ens224
  }

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ability to use specific interface for each VIP Add support for multiple services on the same ip
6 participants