Skip to content

Commit 86c0131

Browse files
committed
OSSMDOC-463: Verify sidecar injection with Kiali.
1 parent 12791fc commit 86c0131

9 files changed

+246
-45
lines changed

images/ossm-icon-missing-sidecar.png

3.69 KB
Loading
Lines changed: 119 additions & 0 deletions
Loading

modules/ossm-automatic-sidecar-injection.adoc

Lines changed: 40 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -7,63 +7,76 @@
77
[id="ossm-automatic-sidecar-injection_{context}"]
88
= Enabling automatic sidecar injection
99

10-
When deploying an application, you must opt-in to injection by setting the `sidecar.istio.io/inject` annotation to `"true"`. Opting in ensures that the sidecar injection does not interfere with other {product-title} features such as builder pods used by numerous frameworks within the {product-title} ecosystem.
10+
When deploying an application, you must opt-in to injection by configuring the annotation `sidecar.istio.io/inject` in `spec.template.metadata.annotations` to `true` in the `deployment` object. Opting in ensures that the sidecar injection does not interfere with other {product-title} features such as builder pods used by numerous frameworks within the {product-title} ecosystem.
1111

1212
.Prerequisites
1313

14-
* Identify the deployments for which you want to enable automatic sidecar injection.
14+
* Identify the namespaces that are part of your service mesh and the deployments that need automatic sidecar injection.
1515
1616
.Procedure
1717

18-
. Open the application's deployment configuration YAML file in an editor. To find a deployment use the `oc get` command. For example, for an app called `sleep` in the `sleep` namespace, use the following command to see the resource in YAML format.
18+
. To find your deployments use the `oc get` command.
1919
+
2020
[source,terminal]
2121
----
22-
$ oc get deployment sleep -o yaml
22+
$ oc get deployment -n <namespace>
2323
----
24+
+
25+
For example, to view the deployment file for the 'ratings-v1' microservice in the `bookinfo` namespace, use the following command to see the resource in YAML format.
26+
+
27+
[source,terminal]
28+
----
29+
oc get deployment -n bookinfo ratings-v1 -o yaml
30+
----
31+
+
32+
. Open the application's deployment configuration YAML file in an editor.
2433

25-
. Add `sidecar.istio.io/inject` to the configuration YAML with a value of `"true"` in the `spec.template.metadata.annotations.sidecar.istio/inject` field. See the following example for an app called `sleep`.
34+
. Add `spec.template.metadata.annotations.sidecar.istio/inject` to your Deployment YAML and set `sidecar.istio.io/inject` to `true` as shown in the following example.
2635
+
27-
.Sleep test application example sleep.yaml
36+
.Example snippet from bookinfo deployment-ratings-v1.yaml
2837
[source,yaml]
2938
----
3039
apiVersion: apps/v1
3140
kind: Deployment
3241
metadata:
42+
name: ratings-v1
43+
namespace: bookinfo
3344
labels:
34-
app: sleep
35-
name: sleep
45+
app: ratings
46+
version: v1
3647
spec:
37-
replicas: 1
38-
selector:
39-
matchLabels:
40-
app: sleep
4148
template:
4249
metadata:
4350
annotations:
44-
sidecar.istio.io/inject: "true"
45-
labels:
46-
app: sleep
47-
spec:
48-
containers:
49-
- name: sleep
50-
image: curlimages/curl
51-
command: ["/bin/sleep","3650d"]
52-
imagePullPolicy: IfNotPresent
51+
sidecar.istio.io/inject: 'true'
5352
----
53+
+
54+
. Save the Deployment configuration file.
5455

55-
. Save the configuration file.
56-
57-
. Add the file back to the project that contains your app. In this example, `sleep` is the name of the project that contains the `sleep` app and `sleep.yaml` is the file you edited.
56+
. Add the file back to the project that contains your app.
5857
+
5958
[source,terminal]
6059
----
61-
$ oc apply -n sleep -f sleep.yaml
60+
$ oc apply -n <namespace> -f deployment.yaml
6261
----
63-
62+
+
63+
In this example, `bookinfo` is the name of the project that contains the `ratings-v1` app and `deployment-ratings-v1.yaml` is the file you edited.
64+
+
65+
[source,terminal]
66+
----
67+
$ oc apply -n bookinfo -f deployment-ratings-v1.yaml
68+
----
69+
+
6470
. To verify that the resource uploaded successfully, run the following command.
6571
+
6672
[source,terminal]
6773
----
68-
$ oc get deployment sleep -o yaml
74+
$ oc get deployment -n <namespace> <deploymentName> -o yaml
75+
----
76+
+
77+
For example,
78+
+
79+
[source,terminal]
80+
----
81+
$ oc get deployment -n bookinfo ratings-v1 -o yaml
6982
----

modules/ossm-kiali-viewing-logs.adoc

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -11,13 +11,12 @@ You can view logs for your workloads in the Kiali console. The *Workload Detail
1111

1212
To change the logging level on the logs displayed in Kiali, you change the logging configuration for the workload or the proxy.
1313

14-
// TODO once released - Kiali can also add-in trace span information to help identify important traces based on associated logging. More powerful features include substring or regex Show/Hide, full-screen, and the ability to set proxy log level without a pod restart.
15-
1614
.Prerequisites
1715

1816
* Service Mesh installed and configured.
1917
* Kiali installed and configured.
2018
* The address for the Kiali console.
19+
* Application or Bookinfo sample application added to the mesh.
2120
2221
.Procedure
2322

@@ -31,6 +30,11 @@ The Kiali Overview page displays namespaces that have been added to the mesh tha
3130

3231
. On the *Workloads* page, select the project from the *Namespace* menu.
3332

34-
. If necessary, use the filter to find the workload whose logs you want to view. Click the workload *Name*.
33+
. If necessary, use the filter to find the workload whose logs you want to view. Click the workload *Name*. For example, click *ratings-v1*.
3534

3635
. On the *Workload Details* page, click the *Logs* tab to view the logs for the workload.
36+
37+
[TIP]
38+
====
39+
If you do not see any log entries, you may need to adjust either the Time Range or the Refresh interval.
40+
====

modules/ossm-sidecar-injection-env-var.adoc

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,13 @@
33
// * service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc
44
// * service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc
55

6+
:_content-type: CONCEPT
67
[id="ossm-sidecar-injection-env-var_{context}"]
7-
= Setting environment variables on the proxy in applications through annotations
8+
= Setting proxy environment variables through annotations
89

9-
You can set environment variables on the sidecar proxy for applications by adding pod annotations in the deployment in the `injection-template.yaml` file. The environment variables are injected to the sidecar.
10+
Configuration for the Envoy sidecar proxies is managed by the `ServiceMeshControlPlane`.
11+
12+
You can set environment variables for the sidecar proxy for applications by adding pod annotations to the deployment in the `injection-template.yaml` file. The environment variables are injected to the sidecar.
1013

1114
.Example injection-template.yaml
1215
[source,yaml]
@@ -28,5 +31,5 @@ spec:
2831

2932
[WARNING]
3033
====
31-
`maistra.io/` labels and annotations should never be included in user-created resources, because they indicate that the resources are generated and managed by the Operator. If you are copying content from an Operator-generated resource when creating your own resources, do not include labels or annotations that start with `maistra.io/` or your resource will be overwritten or deleted by the Operator during the next reconciliation.
34+
You should never include `maistra.io/` labels and annotations when creating your own custom resources. These labels and annotations indicate that the resources are generated and managed by the Operator. If you are copying content from an Operator-generated resource when creating your own resources, do not include labels or annotations that start with `maistra.io/`. Resources that include these labels or annotations will be overwritten or deleted by the Operator during the next reconciliation.
3235
====
Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
////
2+
This module included in the following assemblies:
3+
* service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc
4+
////
5+
:_content-type: CONCEPT
6+
[id="ossm-validating-sidecar_{context}"]
7+
= Validating sidecar injection
8+
9+
The Kiali console offers several ways to validate whether or not your applications, services, and workloads have a sidecar proxy.
10+
11+
.Missing sidecar badge
12+
image::ossm-node-badge-missing-sidecar.svg[Missing Sidecar badge]
13+
14+
The *Graph* page displays a node badge indicating a *Missing Sidecar* on the following graphs:
15+
16+
* App graph
17+
* Versioned app graph
18+
* Workload graph
19+
20+
.Missing sidecar icon
21+
image::ossm-icon-missing-sidecar.png[Missing Sidecar icon]
22+
23+
The *Applications* page displays a *Missing Sidecar* icon in the *Details* column for any applications in a namespace that do not have a sidecar.
24+
25+
The *Workloads* page displays a *Missing Sidecar* icon in the *Details* column for any applications in a namespace that do not have a sidecar.
26+
27+
The *Services* page displays a *Missing Sidecar* icon in the *Details* column for any applications in a namespace that do not have a sidecar. When there are multiple versions of a service, you use the *Service Details* page to view *Missing Sidecar* icons.
28+
29+
The *Workload Details* page has a special unified *Logs* tab that lets you view and correlate application and proxy logs. You can view the Envoy logs as another way to validate sidecar injection for your application workloads.
30+
31+
The *Workload Details* page also has an *Envoy* tab for any workload that is an Envoy proxy or has been injected with an Envoy proxy. This tab displays a built-in Envoy dashboard that includes subtabs for *Clusters*, *Listeners*, *Routes*, *Bootstrap*, *Config*, and *Metrics*.

modules/ossm-update-app-sidecar.adoc

Lines changed: 6 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,13 @@
11
// Module included in the following assemblies:
22
//
3-
// * service_mesh/v1x/installing-ossm.adoc
4-
// * service_mesh/v2x/installing-ossm.adoc
3+
// * service_mesh/v1x/prepare-to-deploy-applications-ossm.adoc
4+
// * service_mesh/v2x/prepare-to-deploy-applications-ossm.adoc
55

6+
:_content-type: PROCEDURE
67
[id="ossm-update-app-sidecar_{context}"]
7-
= Updating your application pods
8+
= Updating sidecar proxies
89

9-
If you selected the Automatic Approval Strategy when you were installing your Operators, then the Operators update the control plane automatically but not your applications. Existing applications continue to be part of the mesh and function accordingly. The application administrator must restart applications to upgrade the sidecar.
10+
In order to update the configuration for sidecar proxies the application administrator must restart the application pods.
1011

1112
If your deployment uses automatic sidecar injection, you can update the pod template in the deployment by adding or modifying an annotation. Run the following command to redeploy the pods:
1213

@@ -15,4 +16,4 @@ If your deployment uses automatic sidecar injection, you can update the pod temp
1516
$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'
1617
----
1718

18-
If your deployment does not use automatic sidecar injection, you must manually update the sidecars by modifying the sidecar container image specified in the deployment or pod.
19+
If your deployment does not use automatic sidecar injection, you must manually update the sidecars by modifying the sidecar container image specified in the deployment or pod, and then restart the pods.

modules/ossm-vs-istio.adoc

Lines changed: 24 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
Module included in the following assemblies:
33
-service_mesh/v2x/ossm-vs-community.adoc
44
////
5-
5+
:_content-type: CONCEPT
66
[id="ossm-vs-istio_{context}"]
77
= Differences between Istio and {SMProductName}
88

@@ -29,6 +29,29 @@ The upstream Istio community installation automatically injects the sidecar into
2929

3030
{SMProductName} does not automatically inject the sidecar to any pods, but requires you to opt in to injection using an annotation without labeling projects. This method requires fewer privileges and does not conflict with other OpenShift capabilities such as builder pods. To enable automatic injection you specify the `sidecar.istio.io/inject` annotation as described in the Automatic sidecar injection section.
3131

32+
////
33+
Hold for OSSMDOC-547 as to what we support
34+
.Sidecar injection label and annotation settings
35+
[options="header"]
36+
[cols="a, a, a"]
37+
|===
38+
|
39+
|Upstream Istio
40+
|{ProductName}
41+
42+
|Namespace Label
43+
|supports "enabled" and "disabled"
44+
|not supported
45+
46+
|Pod Label
47+
|supports "true" and "false"
48+
|not supported
49+
50+
|Pod Annotation
51+
|supports "false" only
52+
|"true" and "false"
53+
|===
54+
////
3255
[id="ossm-rbac_{context}"]
3356
== Istio Role Based Access Control features
3457

0 commit comments

Comments
 (0)