2017-02-17 3 views
0

Ich versuche derzeit, meinen Kopf um k8s und linkerd zu bekommen. Ich habe früher Docker-Compose und Consul benutzt.Linkerd, K8s und Routing

Ich habe nicht ganz herausgefunden, was ich falsch gemacht habe, also würde ich mich freuen, wenn jemand die Logik überprüfen und sehen könnte, wo der Fehler liegt.

Ich verwende lokal minikube und möchte GCE für Bereitstellungen verwenden.

Ich versuche im Grunde, einen einfachen Container zu erhalten, der eine Knotenanwendung ausführt, die in k8s und linkerd ausgeführt wird, aber aus einigen Gründen kann ich das Routing nicht zum Laufen bringen.

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 

I bereitstellen dann ein deamonset von dem ich verstand, dass, dass der vernünftigste Weg 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 eine Replikations Controller mit einer Andockfensters Behälter I dann verwenden, bereitstellen bauen:

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 

Wenn ich dann minikube service l5d eingeben, werden der Dienst und Linkerd angezeigt, aber ich bekomme nicht die Standardseite, die angezeigt werden soll.

Um zu testen, ob alles funktioniert, baue ich einen anderen Dienst, der direkt auf den Port 8080 zeigt und dann funktioniert es, aber nicht über den Linkerd Proxy.

Konnte jemand den Fehler erkennen? Vielen Dank im Voraus.

+0

ich Ihre Frage nicht beantworten kann, aber IMHO ist es nicht notwendig, einen Service-Discovery-Tool Kubernetes hinzuzufügen, da sie es [besitzen hat ] (https://kubernetes.io/docs/user-guide/services/#discovering-services). Dies fügt einfach eine weitere Komplexitätsschicht hinzu, die brechen kann. Der einzige Grund, der mir in den Sinn kommt, ist für Migrationszwecke. – svenwltr

Antwort

1

Dank des linkerd slack Kanal und einige weiteren Versuch, ich schaffte es auf Figur heraus und bauen zwei Dienste auf, die miteinander reden, Daten posten und abrufen. Dies war nur, um den Link Linkerd zu bekommen. Wenn ich etwas Zeit habe, werde ich ein Tutorial darüber schreiben, damit andere daraus lernen können.

ich fehlte ein kubectl Proxy in meinem Replikations Controller:

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

Wir haben das mit einigen zusätzlichen Details im Linkerd Slack besprochen. Das Problem war nicht mit den Configs selbst, sondern mit der Tatsache, dass der Host-Header nicht auf die Anfrage gesetzt wurde.

Die obigen Konfigurationen werden basierend auf dem Hostheader weitergeleitet, daher muss dieser Header einem Dienstnamen entsprechen. curl -H "Host: world" http://$IPADDRESS (oder was auch immer) hätte funktioniert.

(Es ist auch möglich, Route basierend auf anderen Bits der Anfrage, zB URL-Pfad im Fall von HTTP-Anfragen.)