我可以在没有“船长”入口的情况下使用“kube-ingress-aws-controller”吗？

Question

I'm trying to use the ingress of kubernetes on an AWS cluster built with Kops.
I'm following this documentation: https://github.com/kubernetes/kops/tree/master/addons/kube-ingress-aws-controller .
As you can see, I'm using the kube-ingress-aws-controller with the skipper ingress .

For the kube-ingress-aws-controller I have the following script:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-ingress-aws-controller
  namespace: kube-system
  labels:
    application: kube-ingress-aws-controller
    component: ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      application: kube-ingress-aws-controller
      component: ingress
  template:
    metadata:
      labels:
        application: kube-ingress-aws-controller
        component: ingress
    spec:
      serviceAccountName: kube-ingress-aws
      containers:
      - name: controller
        image: registry.opensource.zalan.do/teapot/kube-ingress-aws-controller:latest
        env:
        - name: AWS_REGION
          value: eu-central-1

For the skipper ingress , the script is this one:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: skipper-ingress
  namespace: kube-system
  labels:
    component: ingress
spec:
  selector:
    matchLabels:
      component: ingress
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      name: skipper-ingress
      labels:
        component: ingress
        application: skipper
    spec:
      hostNetwork: true
      serviceAccountName: skipper-ingress
      containers:
      - name: skipper-ingress
        image: registry.opensource.zalan.do/pathfinder/skipper:latest
        ports:
        - name: ingress-port
          containerPort: 9999
          hostPort: 9999
        - name: metrics-port
          containerPort: 9911
        args:
          - "skipper"
          - "-kubernetes"
          - "-kubernetes-in-cluster"
          - "-address=:9999"
          - "-proxy-preserve-host"
          - "-serve-host-metrics"
          - "-enable-ratelimits"
          - "-experimental-upgrade"
          - "-metrics-exp-decay-sample"
          - "-lb-healthcheck-interval=3s"
          - "-metrics-flavour=codahale,prometheus"
          - "-enable-connection-metrics"
        resources:
          requests:
            cpu: 200m
            memory: 200Mi
        readinessProbe:
          httpGet:
            path: /kube-system/healthz
            port: 9999
          initialDelaySeconds: 5
          timeoutSeconds: 5

After that I applied a few more scripts to have a functional prove of concept and everything is working.

QUESTION

what's the point of having both ingresses? What's doing the skipper one?

Shouldn't the kube-ingress-aws-controller be enough?

Answer 1

Ordinary AWS loadbalancers enable TLS termination, automated certificate rotation, possible WAF, and Security Groups but the HTTP routing capabilities are very limited.

Skipper's main advantages compared to other HTTP routers are:

• matching and changing HTTP
• by default with kube-ingress-aws-controller, just work as you would expect.

HAproxy and Nginx are well understood and good TCP/HTTP proxies, that were built before Kubernetes. But they have drawbacks like:

• reliance on static configuration files which comes from a time when routes and their configurations were
• relatively static the list of annotations to implement even basic features are already quite a big list for users

Skipper was built to:

• support dynamically changing route configurations, which happens quite often in Kubernetes
• gives ability to easily implement automated canary deployments, automated blue-green deployments or shadow traffic

However there are some features that have better support in aws-alb-ingress-controller, HAproxy and nginx. For instance the sendfile() operation. If you need to stream a large file or large amount of files, then you may want to go for one of these options.

Aws-alb-ingress-controller directly routes traffic to your Kubernetes services, which is both good and bad, because it can reduce latency, but comes with the risk of depending on kube-proxy routing. kube-proxy routing can take up to 30 seconds, ETCD ttl, for finding pods from dead nodes. Skipper enables: passively observe errors from endpoints and are able to drop these from the loadbalancer members. actively checked member pool, which will enable endpoints if these are healthy again from skipper point of view.

Additionally the aws-alb-ingress-controller does not support features like ALB sharing, or Server Name Indication which can reduce costs. Features like path rewriting are also not currently supported.

Traefik has a good community and support for Kubernetes. Skipper originates from Project Mosaic which was started in 2015. Back then Traefik was not yet a mature project and still had time to go before the v1.0.0 release. Traefik also does not currently support our Opentracing provider. It also did not support traffic splitting when we started stackset-controller for automated traffic switching. We have also recently done significant work on running Skipper as API gateway within Kubernetes, which could potentially help many teams that run a many small services on Kubernetes. Skipper predicates and filters are a powerful abstraction which can enhance the system easily.

So as you can see kube-ingress-aws-controller with the skipper ingress has much more advantages and possibilities comparing to other similar solutions.

More information you can find here: skipper-ingress-controller .