I would like to have the ability to disable the init container via environment variable or annotation, since my cluster security settings do not allow privileged containers.

I will make sure that /proc/sys/net/ipv4/ip_forward = 1 myself.

Thanks in advance.

$ docker run --rm registry.pharos.sh/kontenapharos/akrobateo:0.1.0
{"level":"info","ts":1557739040.1625414,"logger":"cmd","msg":"Akrobateo version: latest"}

We need to make the DRONE_TAG visible in the build container. Now it isn't so the build script defaults to latest.

Hello,

I noticed that If the service type is changed back to NodePort, the load balancer Daemonset is not deleted.

Depends on #1 to get merged so we get "official" images out

Hi there! Love this project and the need for a universal load balancer outside of cloud load balancers.

I've been testing the akrobateo load balancers on a GKE cluster which has 3 worker nodes. It seems that since the cluster has multiple worker nodes that when a service of type:LoadBalancer is created, akrobateo will in turn spin up 3 pods and expose the service port on 3 External IP addresses.

Is there a way with the akrobateo project to act more like a true load balancer where even in a larger worker node cluster the kubernetes service of type:LoadBalancer is only given a single external IP address which acts as the sole entry point into the cluster? Thanks!

Hi,

I tried to create a LoadBalancer with a named port in it

apiVersion: v1
kind: Service
metadata:
  name: nginx-http
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: http
  selector:
    app: nginx

Butn the DS then goes into crashLoop because it does not translate correctly to iptables. Logs:

Setting up forwarding from port 80 to 10.106.7.233:http/TCP
iptables v1.6.2: Port `http' not valid

Try `iptables -h' or 'iptables --help' for more information.

As kubernetes supports using named targetPorts this should imho be supported by the LB provider :)

Some docs are needed :D

Taken from #4, #4 (comment)

Name is a bit too generic..

Some options from #4 (comment)

Service Piper
As in this kinda just makes dumb pipes on the node ports for the services

Cabotage
Cabotage (/ˈkæbətɪdʒ, -tɑːʒ/) is the transport of goods or passengers between two places in the same country by a transport operator from another country.

Service Hauler

Service Liner
The regular and advertised service by vessels between given ports within a particular trade.

Hello,

I tried to deploy this on k8s 1.12.6 by changing an existing service type from NodePort to LoadBalancer. The operator deployment logs shows that it got the event:

{"level":"info","ts":1558264670.0868776,"logger":"service-lb-controller","msg":"Creating a new DS","Request.Namespace":"tqa","Request.Name":"tqa-loadtest-grafana","DS.Namespace":"tqa","DS.Name":"service-lb-tqa-loadtest-grafana"}
{"level":"info","ts":1558264670.2041252,"logger":"service-lb-controller","msg":"Reconciling Service","Request.Namespace":"tqa","Request.Name":"tqa-loadtest-grafana"}
{"level":"info","ts":1558264670.3062572,"logger":"service-lb-controller","msg":"Existing service addresses match, no need to update"}
{"level":"info","ts":1558264670.3077016,"logger":"service-lb-controller","msg":"Reconciling Service","Request.Namespace":"tqa","Request.Name":"tqa-loadtest-grafana"}
{"level":"info","ts":1558264670.3094041,"logger":"service-lb-controller","msg":"Existing service addresses match, no need to update"}

But the DS load balancer POD stayed in crashloopback state without any logs to see what maybe wrong:

service-lb-tqa-loadtest-grafana-jcf9d         0/1     CrashLoopBackOff   7          14m

Also the operator did not show any error logs.

Also when I changed the service type back to NodePort, the daemonset was not deleted.

Any idea what may be wrong? It will be helpful if the LB POD provides some logs as to what issue it may be facing.

For the deployed daemonset.

deployed with deploy folder yamls:

{"level":"info","ts":1558540864.9111614,"logger":"cmd","msg":"failed to initialize service object for metrics: replicasets.apps \"akrobateo-66cccb4bcb\" is forbidden: User \"system:serviceaccount:kube-system:akrobateo\" cannot get resource \"replicasets\" in API group \"apps\" in the namespace \"kube-system\""}
{"level":"info","ts":1558540864.9113507,"logger":"cmd","msg":"Starting the Cmd."}

Using a DaemonSet for LB pods means that a given port can be mapped only in single service per cluster. Then again, a daemonset gives maximum availability. When there's lot of nodes in the cluster a daemonset also results in huge list of external addresses in the service status.

It would be nice to allow the user to select between a deployment and daemonset. The only viable way to configure such things is via annotations on the service. I'd propose the following way:

apiVersion: v1
kind: Service
metadata:
  name: echoserver
  annotations:
    akrobateo.kontena.io/type: deployment # or daemonset
spec:
  type: LoadBalancer
  ports:
  - name: echo
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: echoserver

Hi,
I'm trying to operate Akrobateo as follows:

• Cloned the repo

• Moved to the "deploy" folder

• Run the following command: "kubectl apply -k ."

According to the error I see, it seems the private Docker registry hosting the image for the Akrobateo Pod is out of service as I get the following error: Get https://registry.pharos.sh/v2/: dial tcp 198.54.117.199:443: connect: connection refused"

Any advice would be very much appreciated.

Synopsis

I am following the article at https://blog.kontena.io/akrobateo-general-purpose-loadbalancer-for-k8s/ to setup Akrobateo on my local Kubernetes cluster (bare metal) installed via RKE.

I have removed the default installed RKE ingress-nginx namespace and controller.

I applied 01_role.yaml, 02_service_account.yaml, 03_role_binding.yaml, and 04_operator.yaml without any issues.

I deployed my sample application.

Expected Behavior

Akrobateo should expose the application externally.

> kubectl get services

... should show an external IP address for each of my nodes.

Actual Behavior

Akrobateo pods failed to start. The logs show ip_forward is not enabled.

Looking at akrobateo/lb-image/entrypoint.sh this will happen if cat /proc/sys/net/ipv4/ip_forward doesn't return 0.

I have confirmed on all 3 nodes that...

>cat /proc/sys/net/ipv4/ip_forward
1

> kubectl get services
NAME          TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
hello-world   LoadBalancer   10.43.140.99   <pending>     8080:32766/TCP   26m
kubernetes    ClusterIP      10.43.0.1      <none>        443/TCP          122m

service-lb-postgres-akrobateo-8s7bs   0/1     Terminating   0          38s

I think it ignores SIGTERM signal