Линкерд, к8с и роутинг

Question

Я сейчас пытаюсь разобраться с k8s и linkerd. Я раньше использовал docker-compose и консул.

Я не совсем понял, что я делаю неправильно, поэтому я был бы рад, если бы кто-то мог проверить логику и увидеть, в чем ошибка.

я использую minikube локально и хотел бы использовать GCE для развертываний.

Я в основном пытаюсь получить простой контейнер, который запускает приложение узла, работающее в k8s и linkerd, но по некоторым причинам я не могу заставить работать маршрутизацию.

config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: l5d-config
data:
  config.yaml: |-
    admin:
      port: 9990

    namers:
    - kind: io.l5d.k8s
      experimental: true
      host: localhost
      port: 8001

    routers:
    - protocol: http
      label: outgoing
      baseDtab: |
        /srv        => /#/io.l5d.k8s/default/http;
        /host       => /srv;
        /http/*/*   => /host;
        /host/world => /srv/world-v1;
      interpreter:
        kind: default
        transformers:
        - kind: io.l5d.k8s.daemonset
          namespace: default
          port: incoming
          service: l5d
      servers:
      - port: 4140
        ip: 0.0.0.0

    - protocol: http
      label: incoming
      baseDtab: |
        /srv        => /#/io.l5d.k8s/default/http;
        /host       => /srv;
        /http/*/*   => /host;
        /host/world => /srv/world-v1;
      interpreter:
        kind: default
        transformers:
        - kind: io.l5d.k8s.localnode
      servers:
      - port: 4141
        ip: 0.0.0.0

Я тогда развернуть deamonset из которого я понял, что это самый разумный способ использования linkerd

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  labels:
    app: l5d
  name: l5d
spec:
  template:
    metadata:
      labels:
        app: l5d
    spec:
      volumes:
      - name: l5d-config
        configMap:
          name: "l5d-config"
      containers:
      - name: l5d
        image: buoyantio/linkerd:0.8.6
        env:
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        args:
        - /io.buoyant/linkerd/config/config.yaml
        ports:
        - name: outgoing
          containerPort: 4140
          hostPort: 4140
        - name: incoming
          containerPort: 4141
        - name: admin
          containerPort: 9990
        volumeMounts:
        - name: "l5d-config"
          mountPath: "/io.buoyant/linkerd/config"
          readOnly: true

      - name: kubectl
        image: buoyantio/kubectl:v1.4.0
        args:
        - "proxy"
        - "-p"
        - "8001"

Затем я развертываю контроллер репликации с док-контейнером, который создаю:

apiVersion: v1
kind: ReplicationController
metadata:
  name: testservice
spec:
  replicas: 3
  selector:
    app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      dnsPolicy: ClusterFirst
      containers:
      - name: service
        image: eu.gcr.io/xxxx/testservice:1.0
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: http_proxy
          value: $(NODE_NAME):4140
        command:
        - "pm2-docker"
        - "processes.json"
        ports:
        - name: service
          containerPort: 8080

Когда я тогда вхожу minikube service l5d служба и linkerd показаны, но я не получаю страницу по умолчанию, которая должна быть показана.

Чтобы проверить, все ли работает, я создаю другой сервис, который указывает непосредственно на порт 8080, и затем он работает, но не через прокси linkerd.

Может ли кто-нибудь заметить ошибку? Заранее большое спасибо.

Answer 1

Благодаря слабому каналу linkerd и некоторым дальнейшим попыткам, мне удалось выяснить это и создать два сервиса, которые общаются друг с другом, публикуя и получая данные. Это было только для того, чтобы освоить Linkerd. Когда у меня будет время, я напишу об этом учебник, чтобы другие могли поучиться у него.

Мне не хватало kubectl прокси в моем контроллере репликации:

- name: kubectl
  image: buoyantio/kubectl:1.2.3
  args:
   - proxy
   - "-p"
   - "8001"

Answer 2

Мы обсудили это с некоторыми дополнительными деталями в линкере Slack. Проблема была не в самих конфигах, а в том, что заголовок хоста не был установлен по запросу.

Приведенные выше конфигурации будут маршрутизироваться на основе заголовка хоста, поэтому этот заголовок должен соответствовать имени службы. curl -H "Host: world" http://$IPADDRESS (или что бы то ни было) сработало бы.

(Также возможно маршрутизировать на основе других битов запроса, например, пути URL в случае HTTP-запросов.)