Linkerd, k8s и routing

Question

Я пытаюсь в настоящее время получить голову вокруг k8s и linkerd. Раньше я использовал докер-сочинение раньше и консула.

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

Я использую 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" 

затем развернуть контроллер репликации с Докер контейнера I строительство:

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 слабины и некоторые дополнительные попытки, мне удалось понять это и создавать две службы, которые разговаривают друг с другом, публикуют и получают данные. Это было просто для того, чтобы получить зависть линкерга. Когда у меня будет какое-то время, я напишу учебник об этом, чтобы другие могли учиться на нем.

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

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

Answer 2

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

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

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