4 ms·

By default, all ELBs created by Kubernetes are external, and they load balance traffic to every node in the cluster to the service port (each service gets its o

By default, all ELBs created by Kubernetes are external, and they load balance traffic to every node in the cluster to the service port (each service gets its own port number which is the same in every node).

machbio 10y ago
So, thats a lot of AWS traffic cost for the traffic between different services :(
- danielmartins 10y ago
  That's true if you reference each service via its external ELB CNAME (or a Route53 DNS that points to it); however, Kubernetes comes with a built-in DNS server that you can use to discover the endpoint IP addresses in the pod CIDR (all pods are in the same subnet via the overlay network).
- deleted 10y ago
  [deleted]
- DigitalJack 10y ago
  You can define services to be internal. I presume this does not use an elb but I have not tried it yet.
  - swozey 10y ago
    A lb (glbcd/elb) is only provisioned if you declare type: LoadBalancer. ClusterIP and NodePort don't provision one, and you can always communicate over podIP or via the sky-dns cluster.svc.local records, the former having HA implications.
    - smarterclayton 10y ago
      There has been some work towards having a bare metal IP allocator for metal (you route a subnet to the cluster and when someone adds a Service with type loadbalancer you get handed a magic HA VIP). Not yet in Kube, just OpenShift, but I think we'll eventually work to have it be something you can use if you control your network infra.
      - swozey 10y ago
        Is there any work toward utilizing Openshift Origin on GKE? I'm aware that I can manually configure things to do so but I'd really prefer to to it just be a deployment/daemonset that ties into my GKE instance. This probably affects the customer base of Openshift so I assume it's not likely, but I'd really love to use Openshift on GKE.
- swozey 10y ago
  You can stay within the cluster via connecting with "servicename"(ie, https://mynodeapp/ https://mynodeapp/) - they're added to one another as environment variables. If you need to communicate with another namespace on the cluster you can do servicename.myothernamespace.svc.cluster.local, etc.

machbio 10y ago

So, thats a lot of AWS traffic cost for the traffic between different services :(

danielmartins 10y ago
That's true if you reference each service via its external ELB CNAME (or a Route53 DNS that points to it); however, Kubernetes comes with a built-in DNS server that you can use to discover the endpoint IP addresses in the pod CIDR (all pods are in the same subnet via the overlay network).
deleted 10y ago
[deleted]
DigitalJack 10y ago
You can define services to be internal. I presume this does not use an elb but I have not tried it yet.
- swozey 10y ago
  A lb (glbcd/elb) is only provisioned if you declare type: LoadBalancer. ClusterIP and NodePort don't provision one, and you can always communicate over podIP or via the sky-dns cluster.svc.local records, the former having HA implications.
  - smarterclayton 10y ago
    There has been some work towards having a bare metal IP allocator for metal (you route a subnet to the cluster and when someone adds a Service with type loadbalancer you get handed a magic HA VIP). Not yet in Kube, just OpenShift, but I think we'll eventually work to have it be something you can use if you control your network infra.
    - swozey 10y ago
      Is there any work toward utilizing Openshift Origin on GKE? I'm aware that I can manually configure things to do so but I'd really prefer to to it just be a deployment/daemonset that ties into my GKE instance. This probably affects the customer base of Openshift so I assume it's not likely, but I'd really love to use Openshift on GKE.
swozey 10y ago
You can stay within the cluster via connecting with "servicename"(ie, https://mynodeapp/ https://mynodeapp/) - they're added to one another as environment variables. If you need to communicate with another namespace on the cluster you can do servicename.myothernamespace.svc.cluster.local, etc.