Refractoring and some documentation performed.

This commit is contained in:
savagebidoof
2023-05-01 01:06:33 +02:00
parent b48837e5c0
commit 03a604c91e
146 changed files with 1184 additions and 757 deletions

View File

@ -0,0 +1,6 @@
https://istio.io/latest/docs/tasks/security/authentication/
External authorization system sounds cool
https://istio.io/latest/docs/tasks/security/authorization/authz-custom/

View File

@ -0,0 +1,2 @@
https://raw.githubusercontent.com/istio/istio/release-1.17/samples/httpbin/sample-client/fortio-deploy.yaml

View File

@ -0,0 +1 @@
https://istio.io/latest/blog/2017/0.1-using-network-policy/#examples

View File

@ -0,0 +1,9 @@
https://istio.io/latest/docs/tasks/security/cert-management/
https://istio.io/latest/docs/ops/integrations/certmanager/
https://medium.com/@rd.petrusek/kubernetes-istio-cert-manager-and-lets-encrypt-c3e0822a3aaf
https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/ (it's performed during the installation of Istio)
https://istio.io/latest/docs/tasks/security/cert-management/custom-ca-k8s/ (developement)

View File

@ -0,0 +1,180 @@
---
gitea: none
include_toc: true
---
# Istioctl analyze
`istioctl analyze` reviews the current configuration set.
Can be helpful to spot some improvements on the current configurations set, as well of the possibility of displaying misconfigurations / lack of them that might be causing issues.
```shell
istioctl analyze
```
```text
✔ No validation issues found when analyzing namespace: default.
```
By using the flag -A, it will review from all namespaces
```shell
istioctl analyze -A
```
```text
Info [IST0102] (Namespace istio-operator) The namespace is not enabled for Istio injection. Run 'kubectl label namespace istio-operator istio-injection=enabled' to enable it, or 'kubectl label namespace istio-operator istio-injection=disabled' to explicitly mark it as not needing injection.
Info [IST0118] (Service istio-system/grafana) Port name service (port: 3000, targetPort: 3000) doesn't follow the naming convention of Istio port.
Info [IST0118] (Service istio-system/jaeger-collector) Port name jaeger-collector-grpc (port: 14250, targetPort: 14250) doesn't follow the naming convention of Istio port.
Info [IST0118] (Service istio-system/jaeger-collector) Port name jaeger-collector-http (port: 14268, targetPort: 14268) doesn't follow the naming convention of Istio port.
```
One can specify/target a single namespace by using the flag `-n`
```shell
istioctl analyze -n istio-operator
```
```text
Info [IST0102] (Namespace istio-operator) The namespace is not enabled for Istio injection. Run 'kubectl label namespace istio-operator istio-injection=enabled' to enable it, or 'kubectl label namespace istio-operator istio-injection=disabled' to explicitly mark it as not needing injection.
```
## Example of spotting a misconfiguration
In this example, I have configured the gateway to listen to a port that currently is not open in the Isito Load Balancer selected.
```shell
istioctl analyze
```
```text
Warning [IST0104] (Gateway default/helloworld-gateway) The gateway refers to a port that is not exposed on the workload (pod selector istio=ingressgateway; port 81)
```
# Start the packet capture process on the istio-proxy container from a pod.
Target a pod and start a packet capture on the istio-proxy container.
This step requires Istio to be installed with the flag `values.global.proxy.privileged=true`
This is very useful to confirm if the service is receiving any traffic, or which is the traffic received.
If mTLS is enabled and configured, the traffic received should be encrypted.
```shell
kubectl exec -n default "$(kubectl get pod -n default -l app=helloworld -o jsonpath={.items..metadata.name})" -c istio-proxy -- sudo tcpdump dst port 80 -A
```
```text
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
...
```
# Logs
> **Note:**\
> Remember that you can use the command `watch` or `watch -n 5` (where 5 refers every 5 seconds) in case of being interested on execute this commands periodically.
## Istiod
```shell
kubectl logs -n istio-system -f deployments/istiod
```
## Ingress
The service targeted, `istio-ingressgateway`, is an Ingress Load Balancer service from Istio.
```shell
kubectl logs -n istio-system services/istio-ingressgateway
```
#### Invalid TLS context has neither subject CN nor SAN names
The TLS certificate specified don't have the field CN or the field SAN.
To address this issue, issue a new certificate that has at least one of those fields.
#### initial fetch timed out for type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.Secretthread
This is due not being able to retrieve the TLS configuration assigned to the gateway.
It's Important that the secret is located in the same namespace as the Istio Load Balancer used. In my case is the `istio-system`, but it will vary based on the environment.
# Istioctl proxy-config
## Check listeners
Useful to review which is the configuration assigned to an Istio ingress. / Confirm if the configuration we are intending to deploy is being applied / learned.
### Get Istio ingress pod name
> **Note:**\
> Depending on the ingress gateway set, and your environment, it could be that the Load Balancer is not located in the namespace `istio-system`.
```shell
kubectl get pods -n istio-system
```
```text
NAME READY STATUS RESTARTS AGE
grafana-6cb5b7fbb8-2nlp6 1/1 Running 0 2d3h
istio-ingressgateway-864db96c47-nvjc7 1/1 Running 0 20h
istiod-649d466b9-bwx7j 1/1 Running 0 2d8h
jaeger-cc4688b98-h52xt 1/1 Running 0 2d3h
kiali-594965b98c-zc67p 1/1 Running 0 2d3h
prometheus-67f6764db9-szd5b 2/2 Running 0 2d3h
```
### List listeners
```shell
kubectl get pods -n istio-system istio-ingressgateway-864db96c47-nvjc7
```
```text
istioctl proxy-config listeners -n istio-system istio-ingressgateway-864db96c47-nvjc7
ADDRESS PORT MATCH DESTINATION
0.0.0.0 8443 SNI: lb.net Route: https.443.secure-http.helloworld-gateway.default
0.0.0.0 15021 ALL Inline Route: /healthz/ready*
0.0.0.0 15090 ALL Inline Route: /stats/prometheus*
```
This makes reference to the configuration set in the gateway resources.
Here we can notice a route with SNI match "lb.net", which is listening to the port 443 and HTTPS protocol.
## Check logs verbosity level settings
`istioctl proxy-config log` will display the verbosity level set from each log type for the specified pod.
```shell
istioctl proxy-config log helloworld-nginx-5d99f88767-cwcmd
```
```text
helloworld-nginx-5d99f88767-cwcmd.default:
active loggers:
admin: warning
alternate_protocols_cache: warning
aws: warning
assert: warning
backtrace: warning
cache_filter: warning
client: warning
config: warning
connection: warning
...
```
## List all
It displays ALL from the specified pod.
```shell
istioctl proxy-config all helloworld-nginx-5d99f88767-cwcmd
```
```txt
SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE
80 - inbound ORIGINAL_DST
BlackHoleCluster - - - STATIC
InboundPassthroughClusterIpv4 - - - ORIGINAL_DST
PassthroughCluster - - - ORIGINAL_DST
agent - - - STATIC
...
```

View File

@ -0,0 +1,25 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-nginx
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent #Always
ports:
- containerPort: 80

View File

@ -0,0 +1,14 @@
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"

View File

@ -0,0 +1,236 @@
---
gitea: none
include_toc: true
---
# Description
This is the most basic example, most of the examples spread through this [repository](../../) will be using variants of this.
This example configures:
Generic Kubernetes resources:
- 1 Service
- 1 Deployment
Istio resources:
- 1 Gateway
- 1 Virtual Service
> **Note:**\
> I don't intend to explain thing related to Kubernetes unless necessary.
# Configuration
## Service
Creates a service named `helloworld`.
This service listens for the port `80` expecting `HTTP` traffic and will forward the incoming traffic towards the port `80` from the destination pod.
```yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 80
name: http
selector:
app: helloworld
```
## Deployment
Deploys a Nginx server that listens for the port `80`.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-nginx
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent #Always
ports:
- containerPort: 80
```
## Gateway
Deploys an Istio gateway that's listening to the port `80` for `HTTP` traffic.
It doesn't filter for any specific host.
The `selector` field is used to "choose" which Istio Load Balancers will have this gateway assigned to.
The Istio `default` profile creates a Load Balancer in the namespace `istio-system` that has the label `istio: ingressgateway` set, allowing us to target that specific Load Balancer and assign this gateway resource to it.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
```
## VirtualService
The Virtual Service resources are used to route and filter the received traffic from the gateway resources, and route it towards the desired destination.
On this example we select the gateway `helloworld-gateway`, which is the [gateway that 's described in the `Gateway` section](#gateway).
On this resource, we are also not limiting the incoming traffic to any specific host, allowing for all the incoming traffic to go through the rules set.
Here we created a rule that will be applied on `HTTP` related traffic (including `HTTPS` and `HTTP2`) when the destination path is exactly `/helloworld`.
This traffic will be forwarded to the port `80` of the destination service `helloworld` (the full path URL equivalent would be `helloworld.$NAMESPACE.svc.cluster.local`).
Additionally, there will be an internal URL rewrite set, as if the URL is not modified, it would attempt to reach to the `/helloworld` path from the Nginx deployment, which currently has no content and would result in an error code `404` (Not found).
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld
port:
number: 80
rewrite:
uri: "/"
```
# Walkthrough
## Deploy resources
Deploy the resources.
```shell
kubectl apply -f ./
```
```text
deployment.apps/helloworld-nginx created
gateway.networking.istio.io/helloworld-gateway created
service/helloworld created
virtualservice.networking.istio.io/helloworld-vs created
```
## Wait for the deployment to be ready
Wait for the Nginx deployment to be up and ready.
```shell
kubectl get deployment helloworld-nginx -w
```
```text
NAME READY UP-TO-DATE AVAILABLE AGE
helloworld-nginx 1/1 1 1 44s
```
## Test the service
### Get LB IP
To perform the desired tests, we will need to obtain the IP Istio Load Balancer that we selected in the [Gateway section](#gateway).
On my environment, the IP is the `192.168.1.50`.
```shell
kubectl get svc -l istio=ingressgateway -A
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.47.216 192.168.1.50 15021:31316/TCP,80:32012/TCP,443:32486/TCP 39h
```
### Curl /helloworld
Due to accessing the path `/helloworld`, we are triggering the rule set on the [VirtualService configuration](#virtualservice), sending a request to the Nginx backend and returning us its contents.
```shell
curl 192.168.1.50/helloworld -s | grep "<title>.*</title>"
```
```text
<title>Welcome to nginx!</title>
```
### Curl /other
What happens if we access a path or URL that doesn't trigger any rule?
```shell
curl 192.168.1.50/other -s -I
```
```text
HTTP/1.1 404 Not Found
date: Sun, 30 Apr 2023 22:16:30 GMT
server: istio-envoy
transfer-encoding: chunked
```
We receive a status code `404`.
I would like to put emphasis on the following line returned:
```text
server: istio-envoy
```
This means that the contents returned was performed by the Istio service, instead of the Nginx or any other possible backend service.
## Cleanup
Finally, a cleanup from the resources deployed.
```shell
kubectl delete -f ./
```
```text
deployment.apps "helloworld-nginx" deleted
gateway.networking.istio.io "helloworld-gateway" deleted
service "helloworld" deleted
virtualservice.networking.istio.io "helloworld-vs" deleted
```

View File

@ -0,0 +1,13 @@
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 80
name: http
selector:
app: helloworld

View File

@ -0,0 +1,20 @@
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld
port:
number: 80
rewrite:
uri: "/"

View File

@ -0,0 +1,52 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: httpd
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---

View File

@ -0,0 +1,14 @@
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"

View File

@ -0,0 +1,306 @@
---
gitea: none
include_toc: true
---
# Description
This example deploys the same infrastructure as the [previous example](../01-hello_world_1_service_1_deployment), this time containing 2 deployments under the same service.
This example configures:
Generic Kubernetes resources:
- 1 Service
- 2 Deployments
Istio resources:
- 1 Gateway
- 1 Virtual Service
# Based on
- [01-hello_world_1_service_1_deployment](../01-hello_world_1_service_1_deployment)
# Configuration
## Service
Creates a service named `helloworld`.
This service listens for the port `80` expecting `HTTP` traffic and will forward the incoming traffic towards the port `80` from the destination pod.
```yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 80
name: http
selector:
app: helloworld
```
## Deployment
### helloworld-v1
Deploys a Nginx server that listens for the port `80`.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
```
### helloworld-v2
Deploys an Apache server that listens for the port `80`.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: helloworld
image: httpd
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
```
## Gateway
Deploys an Istio gateway that's listening to the port `80` for `HTTP` traffic.
It doesn't filter for any specific host.
The `selector` field is used to "choose" which Istio Load Balancers will have this gateway assigned to.
The Istio `default` profile creates a Load Balancer in the namespace `istio-system` that has the label `istio: ingressgateway` set, allowing us to target that specific Load Balancer and assign this gateway resource to it.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
```
## VirtualService
The Virtual Service resources are used to route and filter the received traffic from the gateway resources, and route it towards the desired destination.
On this example we select the gateway `helloworld-gateway`, which is the [gateway that 's described in the `Gateway` section](#gateway).
On this resource, we are also not limiting the incoming traffic to any specific host, allowing for all the incoming traffic to go through the rules set.
Here we created a rule that will be applied on `HTTP` related traffic (including `HTTPS` and `HTTP2`) when the destination path is exactly `/helloworld`.
This traffic will be forwarded to the port `80` of the destination service `helloworld` (the full path URL equivalent would be `helloworld.$NAMESPACE.svc.cluster.local`).
Additionally, there will be an internal URL rewrite set, as if the URL is not modified, it would attempt to reach to the `/helloworld` path from the Nginx deployment, which currently has no content and would result in an error code `404` (Not found).
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld
port:
number: 80
rewrite:
uri: "/"
```
# Walkthrough
## Deploy resources
Deploy the resources.
```shell
kubectl apply -f ./
```
```text
deployment.apps/helloworld-v1 created
deployment.apps/helloworld-v2 created
gateway.networking.istio.io/helloworld-gateway created
service/helloworld created
virtualservice.networking.istio.io/helloworld-vs created
```
## Wait for the pods to be ready
Wait for the Apache and Nginx deployments to be up and ready.
```shell
kubectl get deployment helloworld-v{1..2} -w
```
```text
NAME READY UP-TO-DATE AVAILABLE AGE
helloworld-v1 1/1 1 1 4m1s
helloworld-v2 1/1 1 1 4m1s
```
## Test the service
### Get LB IP
To perform the desired tests, we will need to obtain the IP Istio Load Balancer that we selected in the [Gateway section](#gateway).
On my environment, the IP is the `192.168.1.50`.
```shell
kubectl get svc -l istio=ingressgateway -A
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.47.216 192.168.1.50 15021:31316/TCP,80:32012/TCP,443:32486/TCP 39h
```
### Curl
Performing a series of `curl` requests, we can observe how the response iterate between the Nginx and Apache backends.
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<h1>Welcome to nginx!</h1>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<html><body><h1>It works!</h1></body></html>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<h1>Welcome to nginx!</h1>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<html><body><h1>It works!</h1></body></html>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<h1>Welcome to nginx!</h1>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<html><body><h1>It works!</h1></body></html>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<h1>Welcome to nginx!</h1>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<h1>Welcome to nginx!</h1>
```
```shell
curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
```
```text
<html><body><h1>It works!</h1></body></html>
```
## Cleanup
Finally, a cleanup from the resources deployed.
```shell
kubectl delete -f ./
```
```text
deployment.apps "helloworld-v1" deleted
deployment.apps "helloworld-v2" deleted
gateway.networking.istio.io "helloworld-gateway" deleted
service "helloworld" deleted
virtualservice.networking.istio.io "helloworld-vs" deleted
```

View File

@ -0,0 +1,13 @@
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 80
name: http
selector:
app: helloworld

View File

@ -0,0 +1,20 @@
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld
port:
number: 80
rewrite:
uri: "/"

View File

@ -0,0 +1,59 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
version: v1
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v1
template:
metadata:
labels:
app: helloworld
version: v1
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
version: v2
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v2
template:
metadata:
labels:
app: helloworld
version: v2
spec:
containers:
- name: helloworld
image: httpd
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80

View File

@ -0,0 +1,16 @@
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
# name: helloworld (OLD)
name: helloworld.default.svc.cluster.local # Destination that will "interject"
namespace: default
spec:
# host: helloworld # destination service (OLD)
host: helloworld.default.svc.cluster.local # Full destination service, lil better for consistency
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2

View File

@ -0,0 +1,15 @@
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
namespace: default
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"

View File

@ -0,0 +1,426 @@
---
gitea: none
include_toc: true
---
# Description
Based on the [previous example](../02-hello_world_1_service_2_deployments_unmanaged), where we created 2 deployments under the same service, we will attribute different tags to each Deployment, and afterwards, through the usage of a [DestinationRule](#destinationrule), internationally target the desired backend to route the traffic towards it.
This is example is based on the following post regarding [canary deployments on Istio](https://istio.io/latest/blog/2017/0.1-canary/).
This example configures:
Generic Kubernetes resources:
- 1 Service
- 2 Deployments
Istio resources:
- 1 Gateway
- 1 Virtual Service
- 1 Destination rule
Additionally, for consistency, now the resources are being created in the `default` namespace.
As well, on the [VirtualService section](#virtualservice), we are targeting the service `helloworld` by the full URL, where on previous examples it was targeted by `helloworld`, now it's targeted by `helloworld.default.svc.cluster.local`.
# Based on
- [02-hello_world_1_service_2_deployments_unmanaged](../02-hello_world_1_service_2_deployments_unmanaged)
# Configuration
## Service
Creates a service named `helloworld`.
This service listens for the port `80` expecting `HTTP` traffic and will forward the incoming traffic towards the port `80` from the destination pod.
```yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 80
name: http
selector:
app: helloworld
```
## Deployment
### helloworld-v1
Deploys a Nginx server that listens for the port `80`.
On this deployment, we attributed the label `version` set to `v1`, this will be used by the [DestinationRule](#destinationrule) resource to target this deployment.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
labels:
app: helloworld
version: v1
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v1
template:
metadata:
labels:
app: helloworld
version: v1
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
```
### helloworld-v2
Deploys an Apache server that listens for the port `80`.
On this deployment, we attributed the label `version` set to `v2`, this will be used by the [DestinationRule](#destinationrule) resource to target this deployment.
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
labels:
app: helloworld
version: v2
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v2
template:
metadata:
labels:
app: helloworld
version: v2
spec:
containers:
- name: helloworld
image: httpd
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
```
## Gateway
Deploys an Istio gateway that's listening to the port `80` for `HTTP` traffic.
It doesn't filter for any specific host.
The `selector` field is used to "choose" which Istio Load Balancers will have this gateway assigned to.
The Istio `default` profile creates a Load Balancer in the namespace `istio-system` that has the label `istio: ingressgateway` set, allowing us to target that specific Load Balancer and assign this gateway resource to it.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
namespace: default
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
```
## VirtualService
The Virtual Service resources are used to route and filter the received traffic from the gateway resources, and route it towards the desired destination.
On this example we select the gateway `helloworld-gateway`, which is the [gateway that 's described in the `Gateway` section](#gateway).
On this resource, we are also not limiting the incoming traffic to any specific host, allowing for all the incoming traffic to go through the rules set.
Here we created a rule that will be applied on `HTTP` related traffic (including `HTTPS` and `HTTP2`) when the destination path is exactly `/helloworld`.
This traffic will be forwarded to the port `80` of the destination service `helloworld` (the full path URL equivalent would be `helloworld.$NAMESPACE.svc.cluster.local`).
There will be an internal URL rewrite set, as if the URL is not modified, it would attempt to reach to the `/helloworld` path from the Nginx deployment, which currently has no content and would result in an error code `404` (Not found).
Also, there's been configured 2 destinations under the same rule, each one with a `subset` set, which will be used by the [DestinationRule](#destinationrule) object to manage the traffic from each destination.
As well, where each one of the destinations mentioned, has a `weight` set, this value will be used to distribute the incoming requests towards the specified subsets.
> **Note:**
> A 20% of the traffic will be sent to the `subset` v1, meanwhile 80% will be sent to the `subset` v2.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
namespace: default
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld.default.svc.cluster.local
# host: helloworld (OLD)
port:
number: 80
subset: v1
weight: 20
- destination:
# host: helloworld (OLD)
host: helloworld.default.svc.cluster.local
port:
number: 80
subset: v2
weight: 80
rewrite:
uri: "/"
```
## Destination rule
This `DestinationRule` interferes with the traffic with destination `helloworld.default.svc.cluster.local`.
Contains 2 subsets defined, where each one will target a different backend.
A reminder that the `version: v1` was given to the Nginx backend, meanwhile the Apache backend had set `version: v2`.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
# name: helloworld (OLD)
name: helloworld.default.svc.cluster.local # Destination that will "interject"
namespace: default
spec:
# host: helloworld # destination service (OLD)
host: helloworld.default.svc.cluster.local # Full destination service, lil better for consistency
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
```
# Walkthrough
## Deploy resources
Deploy the resources.
```shell
kubectl apply -f ./
```
```text
deployment.apps/helloworld-v1 created
deployment.apps/helloworld-v2 created
destinationrule.networking.istio.io/helloworld.default.svc.cluster.local created
gateway.networking.istio.io/helloworld-gateway created
service/helloworld created
virtualservice.networking.istio.io/helloworld-vs created
```
## Wait for the pods to be ready
Wait for the Apache and Nginx deployments to be up and ready.
```shell
watch -n 2 kubectl get deployment helloworld-v{1..2}
```
```text
NAME READY UP-TO-DATE AVAILABLE AGE
helloworld-v1 1/1 1 1 58s
helloworld-v2 1/1 1 1 58s
```
## Test the service
### Get LB IP
To perform the desired tests, we will need to obtain the IP Istio Load Balancer that we selected in the [Gateway section](#gateway).
On my environment, the IP is the `192.168.1.50`.
```shell
kubectl get svc -l istio=ingressgateway -A
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.47.216 192.168.1.50 15021:31316/TCP,80:32012/TCP,443:32486/TCP 39h
```
### Curl
By performing a series of curls, we can notice how the output received iterates between Nginx and Apache.
If we take into account the configuration set, and we review the results, we can notice how the ratio is close to the one configured in the [VirtualService](#virtualservice) section.
> Nginx instances (v1): 2 \
> Apache instances (v2): 9
```text
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<h1>Welcome to nginx!</h1>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<h1>Welcome to nginx!</h1>
```
## Check Istio internal configurations created
Using the command `istioctl x describe pod $POD`, we can see which Istio configuration is currently attributed to that specific pod.
### v1
We can notice the following line:
`Weight 20%`
Which matches the configuration set in the [VirtualService](#virtualservice) configuration.
```sh
istioctl x describe pod $(kubectl get pod -l app=helloworld,version=v1 -o jsonpath='{.items[0].metadata.name}')
```
```text
Pod: helloworld-v1-7454b56b86-4cksf
Pod Revision: default
Pod Ports: 80 (helloworld), 15090 (istio-proxy)
--------------------
Service: helloworld
Port: http 80/HTTP targets pod port 80
DestinationRule: helloworld for "helloworld.default.svc.cluster.local"
Matching subsets: v1
(Non-matching subsets v2)
No Traffic Policy
--------------------
Effective PeerAuthentication:
Workload mTLS mode: PERMISSIVE
Exposed on Ingress Gateway http://192.168.1.50
VirtualService: helloworld-vs
Weight 20%
/helloworld
```
### v2
We can notice the following line:
`Weight 80%`
Which matches the configuration set in the [VirtualService](#virtualservice) configuration.
```shell
istioctl x describe pod `kubectl get pod -l app=helloworld,version=v2 -o jsonpath='{.items[0].metadata.name
```
```text
Pod: helloworld-v2-64b5656d99-5bwgr
Pod Revision: default
Pod Ports: 80 (helloworld), 15090 (istio-proxy)
--------------------
Service: helloworld
Port: http 80/HTTP targets pod port 80
DestinationRule: helloworld for "helloworld.default.svc.cluster.local"
Matching subsets: v2
(Non-matching subsets v1)
No Traffic Policy
--------------------
Effective PeerAuthentication:
Workload mTLS mode: PERMISSIVE
Exposed on Ingress Gateway http://192.168.1.50
VirtualService: helloworld-vs
Weight 80%
/helloworld
```
## Cleanup
Finally, a cleanup from the resources deployed.
```shell
kubectl delete -f ./
```
```text
deployment.apps "helloworld-v1" deleted
deployment.apps "helloworld-v2" deleted
destinationrule.networking.istio.io "helloworld.default.svc.cluster.local" deleted
gateway.networking.istio.io "helloworld-gateway" deleted
service "helloworld" deleted
virtualservice.networking.istio.io "helloworld-vs" deleted
```
# Links of Interest
- https://istio.io/latest/blog/2017/0.1-canary/
- https://istio.io/latest/docs/reference/config/networking/destination-rule/#DestinationRule

View File

@ -0,0 +1,14 @@
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
namespace: default
spec:
ports:
- port: 80
name: http
selector:
app: helloworld

View File

@ -0,0 +1,31 @@
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
namespace: default
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld.default.svc.cluster.local
# host: helloworld (OLD)
port:
number: 80
subset: v1
weight: 20
- destination:
# host: helloworld (OLD)
host: helloworld.default.svc.cluster.local
port:
number: 80
subset: v2
weight: 80
rewrite:
uri: "/"

View File

@ -0,0 +1,8 @@
apiVersion: v1
kind: Namespace
metadata:
name: defaultnt
labels:
istio-injection: "false"
# istio-injection: "enabled"
---

View File

@ -0,0 +1,123 @@
##### https://github.com/istio/istio/tree/master/samples/helloworld
https://istio.io/latest/blog/2017/0.1-canary/
# Simple Hello World
- 1 Service
- 2 Versions
Iterates between the versions without any specific policy. (actually doesn't use the version for anything)
I think that by default uses `RANDOM`.
https://istio.io/latest/docs/reference/config/networking/destination-rule/#TrafficPolicy-PortTrafficPolicy
https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings
Manually allows the sidecar injection through the label in the pod
https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#controlling-the-injection-policy
## Files
- deployment.yaml
- gateway.yaml
## deployment.yaml
### Creates
#### Service
- helloworld
#### Deployments
- helloworld-v1 (Nginx)
- helloworld-v2 (Apache)
## gateway.yaml
### Creates
#### Gateway
##### helloworld-gateway
###### Configuration
```yml
port: 80
istio-ingress: ingressgateway
hosts: "*"
```
#### VirtualService
##### helloworld-vs
###### Configuration
```yaml
hosts: "*"
uri: "/helloworld"
versions:
v1:
weight: "50%"
v2:
weight: "50%"
```
#### Destination Rule
###### Configuration
```yaml
host: helloworld.defaultnt.svc.cluster.local # Full destination service, lil better for consistency
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
```
# Run example
## Deploy resources
```shell
$
```
## Wait for the pods to be ready
(I think it deploys 2 pods as there is the Envoy Proxy pod besides the Nginx deployment)
```shell
```
## Test the service
### Get LB IP
```shell
$ kubectl get svc istio-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.47.216 192.168.1.50 15021:31316/TCP,80:32012/TCP,443:32486/TCP 39h
```
### Curl
```shell
$ curl 192.168.1.50/helloworld -s | grep "<h1>.*</h1>"
<html><body><h1>It works!</h1></body></html>
```

View File

@ -0,0 +1,86 @@
# https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml
---
apiVersion: v1
kind: Service
metadata:
name: helloworld
namespace: defaultnt
labels:
app: helloworldll
service: helloworld
sidecar.istio.io/inject: "false"
spec:
ports:
- port: 80
name: http
selector:
app: helloworld
---
#apiVersion: v1
#kind: ServiceAccount
#metadata:
# name: istio-helloworld
# labels:
# account:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v1
namespace: defaultnt
labels:
app: helloworld
version: v1
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v1
template:
metadata:
labels:
app: helloworld
version: v1
spec:
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-v2
namespace: defaultnt
labels:
app: helloworld
version: v2
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
version: v2
template:
metadata:
labels:
app: helloworld
version: v2
spec:
containers:
- name: helloworld
image: httpd
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
---

View File

@ -0,0 +1,61 @@
# https://github.com/istio/istio/blob/master/samples/helloworld/helloworld-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
namespace: default
spec:
selector:
istio: istio-ingress # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
namespace: default
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helloworld.defaultnt.svc.cluster.local
port:
number: 80
subset: v1
weight: 50
- destination:
host: helloworld.defaultnt.svc.cluster.local
port:
number: 80
subset: v2
weight: 50
rewrite:
uri: "/"
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: helloworld
namespace: defaultnt
spec:
host: helloworld.defaultnt.svc.cluster.local # Full destination service, lil better for consistency
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2

View File

@ -0,0 +1,47 @@
# Getting Started
The idea of these examples is to get yourself familiarized with the basic elements used on Istio, allowing you to explore the documentation as well of proceeding with other examples or tests on your onw.
On these examples you will find the following Istio resources:
- Gateway
- VirtualService
- DestinationRule
# Examples
- 01-hello_world_1_service_1_deployment
- 02-hello_world_1_service_2_deployments_unmanaged
- ALL NEEDS DOCUMENTATION
- 03-hello_world_1_service_2_deployments_managed_version
- 04-hello_world_1_service_2_deployments_managed_version_defaultnt_namespace
- 05-hello_world_1_Service_Entry
# How to get started?
## Install Istio
Follow [this](https://istio.io/latest/docs/setup/getting-started/) guide to install the `default` profile.
Specifically, the steps of [Download Istio](https://istio.io/latest/docs/setup/getting-started/#download) and [Install Istio][https://istio.io/latest/docs/setup/getting-started/#install).
Once this is set, proceed with the rest of the installation.
## Setting up a Cluster?
Consider using this.
It's what I used to set up my labs for testing (which is the environment that I to do this repository/set of examples).
https://gitea.filterhome.xyz/ofilter/ansible_kubernetes_cluster
Also, I have added MetalLB to allow for my Load Balancers to get a Local IP and be available through the local network environment.

View File

@ -0,0 +1,8 @@
FROM nginx
ADD server.conf /etc/nginx/conf.d/default.conf
RUN mkdir -p /var/www/html
RUN echo "<h2>Howdy</h2>" | tee /var/www/html/index.html
RUN openssl req -x509 -sha256 -nodes -days 358000 -subj '/O=SSL EXAMPLE/CN=lb.net' -newkey rsa:2048 -keyout /cert.key -out /cert.crt

View File

@ -0,0 +1,209 @@
# Description
This image was intended to be used on configuration tests or troubleshooting.
URL: [`docker.io/oriolfilter/https-nginx-demo:latest`](https://hub.docker.com/r/oriolfilter/https-nginx-demo)
---
## Breakdown
### Capabilities
- Multi arch
- HTTP
- HTTPS (with built-in certificate)
- HTTP2
- Nginx
### Platforms it was build on:
- linux/amd64
- linux/arm64
- linux/arm/v7
### Dockerfile
The orders given are very simple:
1. Grab the nginx image as a base/template (this allows me to forget about the entrypoint configuration).
2. Take the file `server.conf` and place it in the path `/etc/nginx/conf.d/default.conf` from the container/image.
3. Create the directory `/var/www/html`, and afterwards create a simple index.
4. Create a certificate and a key that will be used on the Nginx to allow HTTPS traffic requests.
```Dockerfile
FROM nginx
ADD server.conf /etc/nginx/conf.d/default.conf
RUN mkdir -p /var/www/html
RUN echo "<h2>Howdy</h2>" | tee /var/www/html/index.html
RUN openssl req -x509 -sha256 -nodes -days 358000 -subj '/O=SSL EXAMPLE/CN=lb.net' -newkey rsa:2048 -keyout /cert.key -out /cert.crt
```
### server.conf
Read it if you please.
The port listens to both port 80 and port 443, for HTTP and HTTPS traffic.
Port 443 has enabled http2.
Could have configured HTTP to HTTPS forwarding, yet this way I can verify the status of the service or configurations through HTTP requests. (also the HTTP to HTTPS forwarding should be handled by the Load Balancer / Ingress)
It uses the certificates generated previously.
```nginx
server {
listen 80;
server_name lb.net;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log info;
add_header Strict-Transport-Security "max-age=7200";
root /var/www/html;
index index.html;
}
server {
listen 443 ssl default_server http2;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;
server_name lb.net;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log info;
ssl on;
ssl_certificate /cert.crt;
ssl_certificate_key /cert.key;
ssl_session_timeout 5m;
add_header Strict-Transport-Security "max-age=7200";
root /var/www/html;
index index.html;
}
```
# Build it yourself
[Used this guide through this process](https://docs.docker.com/build/building/multi-platform/)
# Yes
As far I understood, runs this as privileged to install certain packages / architectures / platforms to your device.
```shell
docker run --privileged --rm tonistiigi/binfmt --install all
```
```text
Unable to find image 'tonistiigi/binfmt:latest' locally
latest: Pulling from tonistiigi/binfmt
8d4d64c318a5: Pull complete
e9c608ddc3cb: Pull complete
Digest: sha256:66e11bea77a5ea9d6f0fe79b57cd2b189b5d15b93a2bdb925be22949232e4e55
Status: Downloaded newer image for tonistiigi/binfmt:latest
installing: arm OK
installing: mips64le OK
installing: mips64 OK
installing: arm64 OK
installing: riscv64 OK
installing: s390x OK
installing: ppc64le OK
{
"supported": [
"linux/amd64",
"linux/arm64",
"linux/riscv64",
"linux/ppc64le",
"linux/s390x",
"linux/386",
"linux/mips64le",
"linux/mips64",
"linux/arm/v7",
"linux/arm/v6"
],
"emulators": [
"qemu-aarch64",
"qemu-arm",
"qemu-mips64",
"qemu-mips64el",
"qemu-ppc64le",
"qemu-riscv64",
"qemu-s390x"
]
}
```
## Create builder profile
```shell
docker buildx create --name mybuilder --driver docker-container --bootstrap
```
```text
[+] Building 2.0s (1/1) FINISHED
=> [internal] booting buildkit 2.0s
=> => pulling image moby/buildkit:buildx-stable-1 1.2s
=> => creating container buildx_buildkit_mybuilder0 0.8s
mybuilder
```
## Use created buildx profile
```shell
docker buildx use mybuilder
```
## Inspect selected buildx profile
```shell
docker buildx inspect
```
```text
Name: mybuilder
Driver: docker-container
Last Activity: 2023-04-25 00:33:29 +0000 UTC
Nodes:
Name: mybuilder0
Endpoint: unix:///var/run/docker.sock
Status: running
Buildkit: v0.11.5
Platforms: linux/amd64, linux/amd64/v2, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
```
## Build, tag and push
I am targeting the repo directly, but any registry can be targeted.
```shell
docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t oriolfilter/https-nginx-demo:latest . --push
```
```text
[+] Building 11.0s (24/24) FINISHED
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 383B 0.0s
=> [linux/arm/v7 internal] load metadata for docker.io/library/nginx:latest 0.8s
=> [linux/arm64 internal] load metadata for docker.io/library/nginx:latest 0.8s
=> [linux/amd64 internal] load metadata for docker.io/library/nginx:latest 0.8s
...
<> Building sounds intensifies <>
...
=> [auth] oriolfilter/https-nginx-demo:pull,push token for registry-1.docker.io
```

View File

@ -0,0 +1,36 @@
server {
listen 80;
server_name lb.net;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log info;
add_header Strict-Transport-Security "max-age=7200";
root /var/www/html;
index index.html;
}
server {
listen 443 ssl default_server http2;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;
server_name lb.net;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log info;
ssl on;
ssl_certificate /cert.crt;
ssl_certificate_key /cert.key;
ssl_session_timeout 5m;
add_header Strict-Transport-Security "max-age=7200";
root /var/www/html;
index index.html;
}

68
NEW/README.md Executable file
View File

@ -0,0 +1,68 @@
# Disclaimer:
I have absolutely used as a reference and or template other party configurations/files.
I have tried to reference as much as possible as long it's relevant/useful for the reader.
Refer to the specific `README.md` in each example for more information, as the documentation is still in progress.
As per the moment, most of the examples are located in 02-Traffic_management.
Currently, the resources are under a relocation and the folders might contain things that don't _really match the topic_.
# Stuff
## Glossary
https://istio.io/latest/docs/reference/glossary/
## Workload
https://istio.io/latest/docs/reference/glossary/#workload
https://kiali.io/docs/architecture/terminology/concepts/#workload
https://istio.io/latest/docs/ops/deployment/vm-architecture/
## Sidecar
https://kubebyexample.com/learning-paths/istio/intro
# Notes for myself
Internal and external authentication should be set together.
https://istio.io/latest/docs/ops/diagnostic-tools/proxy-cmd/
https://istio.io/latest/docs/ops/deployment/deployment-models/
## Services port names
Istio allows to specify which protocol will run through a port.
It requires the name of the port to be set to a specific format `name: <protocol>(-<suffix>)`.
Starting from Kubernetes 1.18, it also can be specified through the `appProtocol` field in the port, resulting in `appProtocol: <protocol>`.
This means that port names should respect this format to avoid issues, and for such be cautious when setting up the name of the ports.
This applies to multiple Istio elements, but as well to `kind: Services` from default Kubernetes.
For more information about this behavior, refer to:
https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection
# Workload selector is cool
- https://istio.io/latest/docs/reference/config/type/workload-selector/#WorkloadSelector
# Links of interest
- https://istiobyexample.dev/