Answers: <p>Well there are 2 possibble options.</p>
  
  <p>One is to create a <strong>LoadBalancer</strong> type for each service you want to be exposed. In case you have just one service that's great. That's rarely the case of course :) </p>
  
  <p>If you build your k8s cluster properly ( having Prometheus-Operator doing the monitoring for example ) most likely besides the business logic service/s, you would want to expose  internal cluster valuable services like Grafana.</p>
  
  <p>That's why even if you have just 1 service, for future extension of such type of need the best would be to use an <strong>Ingress</strong> resource. It providees a way to expose multiple services through a single IP address —  HTTP level (network layer 7). </p>
  
  <p>You could play with HTTP headers essentially and do some path/host routing.</p>
  
  <p>You express the definition for your object and helm would do the installation. Another option is to use a tool like ArgoCD, basically sticking to GitOps policy.</p>
  
  <p>A fundamnetal knowledge is to be aware that the Load Balancer/Ingress would forward the traffic to the service, not the pods. Services are abstracted entities by kube-proxy, by default kube-proxy uses a round-robin algorithm.</p>
  
  <p><a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/service/</a></p>
  
  <p>Regarding the definition, it follows the standart K8s scheme [ <strong>apiVersion</strong>, <strong>kind</strong>, <strong>metadata</strong>, <strong>spec</strong> fields]. Example would be an Ingress created from AWS-Ingress-Controller.</p>
  
  <pre class="lang-yaml prettyprint-override"><code>apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: ingress
    namespace: management
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/scheme: internet-facing
  spec:
    rules:
    - host: grafana.com
      http:
        paths:
        - backend:
            serviceName: grafana
            servicePort: 80
          path: /*
  
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2020-03-27T09:37:32.773Z
Answers: 2020-03-27T10:04:37.937Z
Answers: 2020-03-27T10:04:37.937Z
Answers: Recoba20
Body: <p>I am researching different types of <code>loadbalancing</code> methods available through kubernetes .I want to implement &amp; see before deciding on one .I'm stuck at how to actually define <code>typeof-loadbalancer</code>.If it isn't possible through <code>helm</code>  can anyone suggest other options please .</p>
  
Tags: <amazon-web-services><kubernetes><helm><load-balance>
Title: Is there a way through which I can control type of load balancer like round robin , least-connections etc using helm charts?
UserDisplayName: YoganA
ThreadText: # Is there a way through which I can control type of load balancer like round robin , least-connections etc using helm charts?
  
  (Asked by: username_0 on 2020-03-27)
  
  I am researching different types of `loadbalancing` methods available through kubernetes .I want to implement & see before deciding on one .I'm stuck at how to actually define `typeof-loadbalancer`.If it isn't possible through `helm` can anyone suggest other options please .
  
  **Tags:** amazon-web-services, kubernetes, helm, load-balance
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-03-27. Score: 1
  
  Well there are 2 possibble options.
  
  One is to create a **LoadBalancer** type for each service you want to be exposed. In case you have just one service that's great. That's rarely the case of course :)
  
  If you build your k8s cluster properly ( having Prometheus-Operator doing the monitoring for example ) most likely besides the business logic service/s, you would want to expose internal cluster valuable services like Grafana.
  
  That's why even if you have just 1 service, for future extension of such type of need the best would be to use an **Ingress** resource. It providees a way to expose multiple services through a single IP address — HTTP level (network layer 7).
  
  You could play with HTTP headers essentially and do some path/host routing.
  
  You express the definition for your object and helm would do the installation. Another option is to use a tool like ArgoCD, basically sticking to GitOps policy.
  
  A fundamnetal knowledge is to be aware that the Load Balancer/Ingress would forward the traffic to the service, not the pods. Services are abstracted entities by kube-proxy, by default kube-proxy uses a round-robin algorithm.
  
  <https://kubernetes.io/docs/concepts/services-networking/service/>
  
  Regarding the definition, it follows the standart K8s scheme [ **apiVersion**, **kind**, **metadata**, **spec** fields]. Example would be an Ingress created from AWS-Ingress-Controller.
  
  ```yaml
  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: ingress
    namespace: management
    annotations:
      kubernetes.io/ingress.class: alb
      alb.ingress.kubernetes.io/scheme: internet-facing
  spec:
    rules:
    - host: grafana.com
      http:
        paths:
        - backend:
            serviceName: grafana
            servicePort: 80
          path: /*
  
  ```
  
  
  ---
  
  