2017-02-17 7 views
0

私は現在、k8sとlinkerdを頭に浮かべています。私はドッカーを使って前にコンサルを作った。Linkerd、k8s、routing

私は間違っていることを完全には分かっていないので、誰かが論理をチェックして間違いがどこにあるかを知ることができたら嬉しいです。

私はローカルで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 

私は、その私はその後、ドッカーコンテナIと複製コントローラを展開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" 

を使用するのが最も賢明な方法であることを、私は理解し、そこからdeamonsetを展開ビルド:

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と入力すると、サービスとリンカーが表示されますが、表示する必要があるデフォルトのページは表示されません。

すべてが機能しているかどうかをテストするには、ポート8080を直接指し示す別のサービスを作成してから動作させますが、linkerdプロキシ経由では機能しません。

誰かがエラーを発見できますか?ありがとうございます。

+0

私はあなたの質問に答えることはできませんが、それはそれは[自分の一つだがあるので、Kubernetesにサービス発見ツールを追加する必要が私見](https://kubernetes.io/docs/user-guide/services/#discovering-services)。これは、壊れるかもしれない別の複雑なレイヤーを追加するだけです。私の心の中にある唯一の理由は、移行目的のためです。 – svenwltr

答えて

1

linkerdスラックチャネルのおかげで、いくつかは、さらにしようと、私はそれを把握するために管理しましたお互いに話し合いながら、投稿してデータを取得する2つのサービスを構築します。これはちょうどリンカーのハングアップを取得することでした。私はしばらくすると、他の人がそれから学ぶことができるようにチュートリアルを書くでしょう。

私は私の複製コントローラにkubectlプロキシを行方不明になった:

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

これについては、Linkerd Slackのいくつかの追加の詳細を参照して説明しました。この問題は、configs自体ではなく、ホストヘッダーが要求に設定されていないという事実と関係していました。

上記の設定はホストヘッダーに基づいて行われるため、このヘッダーはサービス名に対応する必要があります。 curl -H "Host: world" http://$IPADDRESS(または何でも)働いていたでしょう。

(これは、例えばHTTPリクエストの場合、URLパス、要求の他のビットに基づいてルーティングすることも可能です。)