search

asaxon / mesh

service mesh batting practice
0 stars 0 forks source link

Install Kong Mesh #1

Open asaxon opened 8 months ago

asaxon commented 8 months ago

As silly goose, I want to understand service mesh better, by actually working with it, and having the proof.

DoD: Kong mesh is installed locally using Docker in multi-zone fashion AC: Same as above, but managed via groomed sprint (stand ups, planning, retro, yadayada)

Ref implementation: https://docs.konghq.com/mesh/2.4.x/production/install-kumactl/ https://docs.konghq.com/mesh/2.4.x/production/deployment/multi-zone/

asaxon commented 8 months ago

Clicking the docker icon from https://docs.konghq.com/mesh/2.4.x/install/, leads me to https://docs.konghq.com/mesh/2.4.x/production/install-kumactl/. Starting here.

asaxon commented 8 months ago

Read and create resources in Kong Mesh in Universal mode, noting since that's what i'll mess with, not ready for k8s yet.

asaxon commented 8 months ago

wrt to mesh can do facking everything, The only condition is that all the data planes running within the zone must be able to connect to the other data planes in this same zone. interesting

asaxon commented 8 months ago

took note of a problem statement for why kong mesh is a product: Reliable service connectivity, cloud is a disaster with it

asaxon commented 8 months ago

take note: Kong Mesh is a control plane (and it is being shipped in a kuma-cp binary) while Envoy is a data plane proxy (shipped as an envoy binary)

asaxon commented 8 months ago

Service Mesh does not introduce new concerns or use-cases: it addresses a concern that we are already taking care of (usually by writing more code, if we are doing anything at all): dealing with the connectivity in our network.

asaxon commented 8 months ago

mesh dir struct

├── NOTICE ├── README ├── bin │ ├── envoy │ ├── kuma-cp │ ├── kuma-dp │ └── kumactl └── conf └── kuma-cp.conf.yml