etcd-operator icon indicating copy to clipboard operation
etcd-operator copied to clipboard

Allow defining a ClusterIP for the client service in EtcdCluster

Open voor opened this issue 6 years ago • 4 comments

I want to use the etcd-operator in conjunction with coredns etcd plugin. I want to resolve the etcd cluster by Cluster IP Address before creating it, so I want to anticipate the ClusterIP that gets defined to the *-client service definition.

This enhancement would add the ability to specify a spec for the resulting *-client service that is created, similar to the additional spec fields being added for pods.

One approach, would be to add a clusterIP to the existing spec under EtcdCluster, which would get passed down to https://github.com/coreos/etcd-operator/blob/master/pkg/util/k8sutil/k8sutil.go#L161

Looking to see if this is a reasonable request, and is in-line with the principles of the operator.

voor avatar Jan 02 '19 14:01 voor

@voor So if I understand your request you are looking to implement a SRV discovery mechanism to support coredns?

hexfusion avatar Jan 11 '19 14:01 hexfusion

I'm looking to configure my coredns inside kubernetes to contain the following (this is the coredns helm chart)

servers:
  - zones:
      - zone: .
    port: 53
    plugins:
      - name: errors
      - name: health
      - name: kubernetes
        parameters: cluster.local in-addr.arpa ip6.arpa
        configBlock: |-
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
      - name: etcd
        parameters: example.com
        configBlock: |-
          stubzones
          path /skydns
          endpoint http://10.100.200.84:2379 # Copied from `kubectl get svc -n etcd`
      - name: prometheus
        parameters: :9153
      - name: proxy
        parameters: . /etc/resolv.conf
      - name: cache
        parameters: 30
      # - name: loop
      - name: reload
      - name: loadbalance

Note the value for endpoint in the etcd plugin requires an IP Address not a dns resolved name (because this is the DNS for the cluster), so I want to be able to reliable forecast what that ClusterIP will be.

voor avatar Jan 11 '19 14:01 voor

I'm just here to throw my vote in for this as well. I'm deploying coredns alongside etcd (via this operator) in the same umbrella helm chart, knowing/setting the cluster IP would make automating my deployments much more streamlined.

mmiller1 avatar Jun 12 '19 16:06 mmiller1

This is also a useful feature to me. Is it hard to get it implemented?

falfaro avatar Jun 14 '19 06:06 falfaro