Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add istiod service mesh #191

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

sdake
Copy link
Member

@sdake sdake commented Aug 22, 2024

The goal here is to connect a public cloud DNS entry to virtual machines in my home lab. The configuration is derived from the Istio documentation (multi-network, single cluster, automatic worklaodentry creation)

I am not sure why run-curl.sh doesn't complete. The virtual machines are added to the mesh:

sdake@a40x2:~$ istioctl proxy-status
NAME                                                     CLUSTER      CDS        LDS        EDS        RDS        ECDS     ISTIOD                      VERSION
a40x2.vllm                                               cluster1     SYNCED     SYNCED     SYNCED     SYNCED              istiod-67f89ccbd9-5slrc     1.23.0
istio-eastwestgateway-6cb57b485f-f76pv.istio-ingress     cluster1     SYNCED     SYNCED     SYNCED                         istiod-67f89ccbd9-5slrc     1.23.0
istio-ingress-7bd5b47574-zs548.istio-ingress             cluster1     SYNCED     SYNCED     SYNCED     SYNCED              istiod-67f89ccbd9-5slrc     1.23.0

The a40x2.vllm proxy should map to the DNS name vllm.vllm. I have another node not currently shown here (a30x2). This configuration doesn't quite setup automatic workload entry creation. to do that, some environment varibales need to be set.

The workflow is:

bash generate-istio-manifests.sh
kubectl apply -f istio-ns.yaml
kubectl apply -f istio-base.yaml
kubectl apply -f istio-istiod-mutli.yaml
kubectl apply -f istio-gateway-mutli.yaml
kubectl apply -f istio-gateway-eastwest-mutli.yaml
kubectl apply -f meta.yaml
kubectl apply -f expose-istiod.yaml
bash install-vm-files.sh
bash run-curl.sh

This run-curl.sh operation should generate some output, but currently fails. I am not sure if the failure is a misconfiguration, related to a problem with the eastwest gateway and ingress gateway routing, or a defect in istio.

The goal here is to connect a public cloud DNS entry to virtual
machines in my home lab. The configuration is derived from the Istio
documentation (multi-network, single cluster, automatic worklaodentry creation)

I am not sure why `run-curl.sh` doesn't complete. The virtual machines
are added to the mesh:

```
sdake@a40x2:~$ istioctl proxy-status
NAME                                                     CLUSTER      CDS        LDS        EDS        RDS        ECDS     ISTIOD                      VERSION
a40x2.vllm                                               cluster1     SYNCED     SYNCED     SYNCED     SYNCED              istiod-67f89ccbd9-5slrc     1.23.0
istio-eastwestgateway-6cb57b485f-f76pv.istio-ingress     cluster1     SYNCED     SYNCED     SYNCED                         istiod-67f89ccbd9-5slrc     1.23.0
istio-ingress-7bd5b47574-zs548.istio-ingress             cluster1     SYNCED     SYNCED     SYNCED     SYNCED              istiod-67f89ccbd9-5slrc     1.23.0
```

The a40x2.vllm proxy should map to the DNS name vllm.vllm. I have another node
not currently shown here (a30x2). This configuration doesn't quite setup
automatic workload entry creation. to do that, some environment varibales
need to be set.

The workflow is:
```
bash generate-istio-manifests.sh
kubectl apply -f istio-ns.yaml
kubectl apply -f istio-base.yaml
kubectl apply -f istio-istiod-mutli.yaml
kubectl apply -f istio-gateway-mutli.yaml
kubectl apply -f istio-gateway-eastwest-mutli.yaml
kubectl apply -f meta.yaml
kubectl apply -f expose-istiod.yaml
bash install-vm-files.sh
bash run-curl.sh
```

This run-curl.sh operation should generate some output, but currently fails.
I am not sure if the failure is a misconfiguration, related to a problem with
the eastwest gateway and ingress gateway routing, or a defect in istio.
@sdake sdake requested a review from a team as a code owner August 22, 2024 18:16
@cla-bot cla-bot bot added the CLA CLA signed? label Aug 22, 2024
@sdake
Copy link
Member Author

sdake commented Aug 22, 2024

One potential problem is the application of vmnetwork versus kubenetwork. The upstream documentation is lacking here as to how these are used when routing traffic from, for example, the istio-igressgateway, over the istio-eastwestgateway, to the virtual machines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA CLA signed?
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants