github/kata-containers
1
0
Fork 1
mirror of https://github.com/kata-containers/kata-containers.git synced 2025-07-13 15:14:08 +00:00
Code Issues Projects Releases Wiki Activity

docs: Rename conduit to linkerd

Browse Source 
The conduit project seems to have renamed itself to linkerd so update
the service mesh document to reflect that.

Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
This commit is contained in:
James O. D. Hunt 2019-05-01 16:06:23 +01:00
parent 9a99899861
commit b1af8deaec
1 changed files with 21 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
svc-mesh/service-mesh.md
View File

@ -7,10 +7,10 @@
* [Restrictions](#restrictions) * [Restrictions](#restrictions)
* [Install and deploy your service mesh](#install-and-deploy-your-service-mesh) * [Install and deploy your service mesh](#install-and-deploy-your-service-mesh)
* [Service Mesh Istio](#service-mesh-istio) * [Service Mesh Istio](#service-mesh-istio)
* [Service Mesh Conduit](#service-mesh-conduit) * [Service Mesh Linkerd](#service-mesh-linkerd)
* [Inject your services with sidecars](#inject-your-services-with-sidecars) * [Inject your services with sidecars](#inject-your-services-with-sidecars)
* [Sidecar Istio](#sidecar-istio) * [Sidecar Istio](#sidecar-istio)
* [Sidecar Conduit](#sidecar-conduit) * [Sidecar Linkerd](#sidecar-linkerd)
* [Run your services with Kata](#run-your-services-with-kata) * [Run your services with Kata](#run-your-services-with-kata)
* [Lower privileges](#lower-privileges) * [Lower privileges](#lower-privileges)
* [Add annotations](#add-annotations) * [Add annotations](#add-annotations)
@ -28,7 +28,7 @@ __containers__, __control plane__, __data plane__, and __sidecar__.
## How they work ## How they work
Istio and Conduit both rely on the same model, where they run controller Istio and Linkerd both rely on the same model, where they run controller
applications in the control plane, and inject a proxy as a sidecar inside applications in the control plane, and inject a proxy as a sidecar inside
the pod running the service. The proxy registers in the control plane as the pod running the service. The proxy registers in the control plane as
a first step, and it constantly sends different sorts of information about a first step, and it constantly sends different sorts of information about
@ -59,7 +59,7 @@ you choose to annotate run with Kata Containers.
### Restrictions ### Restrictions
As documented [here](https://github.com/runconduit/conduit/issues/982), As documented [here](https://github.com/linkerd/linkerd2/issues/982),
a kernel version between 4.14.22 and 4.14.40 causes a deadlock when a kernel version between 4.14.22 and 4.14.40 causes a deadlock when
`getsockopt()` gets called with the `SO_ORIGINAL_DST` option. Unfortunately, `getsockopt()` gets called with the `SO_ORIGINAL_DST` option. Unfortunately,
both service meshes use this system call with this same option from the both service meshes use this system call with this same option from the
@ -97,26 +97,26 @@ $ kubectl get svc -n istio-system
$ kubectl get pods -n istio-system -o wide $ kubectl get pods -n istio-system -o wide
``` ```
### Service Mesh Conduit ### Service Mesh Linkerd
As a reference, follow the Conduit [instructions](https://conduit.io/getting-started/index.html). As a reference, follow the Linkerd [instructions](https://linkerd.io/2/getting-started/index.html).
The following is a summary of what you need to install Conduit on your system: The following is a summary of what you need to install Linkerd on your system:
``` ```
$ curl https://run.conduit.io/install | sh $ curl https://run.linkerd.io/install | sh
$ export PATH=$PATH:$HOME/.conduit/bin $ export PATH=$PATH:$HOME/.linkerd/bin
``` ```
Now deploy Conduit in the control plane of your cluster with the following: Now deploy Linkerd in the control plane of your cluster with the following:
``` ```
$ conduit install | kubectl apply -f - $ linkerd install | kubectl apply -f -
``` ```
To verify that the control plane is properly deployed, you can use both of To verify that the control plane is properly deployed, you can use both of
the following commands: the following commands:
``` ```
$ kubectl get svc -n conduit $ kubectl get svc -n linkerd
$ kubectl get pods -n conduit -o wide $ kubectl get pods -n linkerd -o wide
``` ```
## Inject your services with sidecars ## Inject your services with sidecars
@ -140,18 +140,17 @@ your YAML file. We use their bookinfo sample as an example:
$ istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml -o bookinfo-injected.yaml $ istioctl kube-inject -f samples/bookinfo/kube/bookinfo.yaml -o bookinfo-injected.yaml
``` ```
### Sidecar Conduit ### Sidecar Linkerd
Conduit provides an [emojivoto](https://conduit.io/getting-started/index.html) Linkerd provides an [emojivoto](https://linkerd.io/2/getting-started/index.html)
sample, which you can rely on to inject their `conduit` proxy as a sample, which you can rely on to inject their `linkerd` proxy as a
sidecar. sidecar.
You need to use their tool called `conduit inject` to inject your YAML You need to use their tool called `linkerd inject` to inject your YAML
file. We use their [emojivoto](https://conduit.io/getting-started/index.html) file. We use their emojivoto sample as example:
sample as example:
``` ```
$ wget https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml $ wget https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml
$ conduit inject emojivoto.yml > emojivoto-injected.yaml $ linkerd inject emojivoto.yml > emojivoto-injected.yaml
``` ```
## Run your services with Kata ## Run your services with Kata
@ -164,7 +163,7 @@ containers, manually edit your deployment to make it work with Kata.
In Kubernetes, the __init__ container is often `privileged` as it needs to In Kubernetes, the __init__ container is often `privileged` as it needs to
setup the environment, which often needs some root privileges. In the case setup the environment, which often needs some root privileges. In the case
of those services meshes, all they need is the `NET_ADMIN` capability to of those services meshes, all they need is the `NET_ADMIN` capability to
modify the underlying network rules. Conduit, by default, does not use modify the underlying network rules. Linkerd, by default, does not use
`privileged` container, but Istio does. `privileged` container, but Istio does.
Because of the previous reason, if you use Istio you need to switch all Because of the previous reason, if you use Istio you need to switch all
@ -172,7 +171,7 @@ containers with `privileged: true` to `privileged: false`.
### Add annotations ### Add annotations
There is no difference between Istio and Conduit in this section. It is There is no difference between Istio and Linkerd in this section. It is
about which CRI implementation you use. about which CRI implementation you use.
For both CRI-O and CRI-containerd, you have to add an annotation indicating For both CRI-O and CRI-containerd, you have to add an annotation indicating