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.
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