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

WIP: Replace configmap with CRD #85

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

WIP: Replace configmap with CRD #85

wants to merge 3 commits into from

Conversation

aledbf
Copy link
Owner

@aledbf aledbf commented Feb 17, 2019

Goals:

  • Replace the configuration configmap with a CRD
  • Improve configuration and validation
  • Reduce the number of resources to define a virtual IP

fixes #80

@aledbf aledbf changed the title Replace configmap with CRD WIP: Replace configmap with CRD Feb 17, 2019
@aledbf
Copy link
Owner Author

aledbf commented Feb 17, 2019

@steven-sheehy @mshaverdo ping. Any feedback or suggestion/feature is welcome :)

@coveralls
Copy link

coveralls commented Feb 17, 2019

Coverage Status

Coverage remained the same at 15.014% when pulling 034c496 on crd into d47a1f8 on master.

Copy link
Contributor

@steven-sheehy steven-sheehy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would this CRD be supported in the Helm chart? Can the user just specify a list of VirtualIPSpec in yaml format and Helm would loop over them and add in the metadata?

)

// VirtualIP is a keepalived CRD specificiation for virtual IP addresses
type VirtualIP struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intent with this CRD that every IP + interface -> Service:port mapping would have a separate definition? That would require quite a bit duplication by the user if they had multiple services on one IP. What about a way to select which services apply by labels?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intent with this CRD that every IP + interface -> Service:port mapping would have a separate definition?

I changed the definition to a list of serviceReferences

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about instead of binding the virtual IP to services in a centralized spot in the CRD, we decentralize it to be an annotation on the service? The annotation would be reference back the CRD's metadata.name. For example:

apiVersion: v1
kind: Service
metadata:
  name: myservice
  annotations:
    keepalived/vip: myvipname
spec:
  externalIPs:
  - 10.0.22.170

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be even nicer if it could populate the externalIPs on the service object. MetalLB does something similar to what I'm suggesting using annotations and modifying service IP:

https://metallb.universe.tf/usage/

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am aware of the externalIPs field but using that also makes validation harder (I am thinking to add a webhook to avoid invalid configuration/duplicated IPs). Also using the service could lead to someone ask for externalTrafficPolicy support

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think people should be aware that externalTrafficPolicy does not apply to externalIPs. We can document it in the README if need be or point to kubernetes docs.

If populating externalIPs is difficult/error prone, what do you think about just the annotation idea to do service binding?

pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
pkg/apis/keepalive/v1beta1/register.go Outdated Show resolved Hide resolved
LVSScheduler *LVSScheduler `json:"lvsScheduler,omitempty"`
// LVSMethod default LVS forwarding method (NAT|DR)
// Default: NAT
LVSMethod *string `json:"lvsMethod,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this one also should be an enum.

// LVSScheduler LVS scheduler (rr|wrr|lc|wlc|lblc|sh|mh|dh|fo|ovf|lblcr|sed|nq)
type LVSScheduler string

const (
Copy link
Contributor

@panpan0000 panpan0000 Apr 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems keepalived supports moer than 4
https://www.keepalived.org/doc/configuration_synopsis.html#virtual-server-definitions-synopsis
it says lb_algo can be rr|wrr|lc|wlc|sh|dh|lblc ?

@panpan0000
Copy link
Contributor

Anyway, it has been more than one month, so looking forward to this CRD feature coming to be merged :-)
@steven-sheehy @aledbf


// Interface interface where the virtual IP should be configured
// The default value is eth0
Interface *string `json:"interface,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be better to detect by CIDR on machine with keepalived controller?

And then may be webhook, to check if interface exists?

@panpan0000
Copy link
Contributor

it seems this proposal has been forgotten ? ^_^

@aledbf
Copy link
Owner Author

aledbf commented Oct 15, 2019

it seems this proposal has been forgotten ? ^_^

Unfortunately, I don't have enough free time to continue with this. that said, this is still in my radar.

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.

5 participants