How to prepare for Istio certified associate exam (ICA)
CNCF announced a new certification targeting Istio. Istio Certified Associate is meant for engineers, CI/CD practitioners or anyone interested in Istio. We did a full week of streams on YouTube, going through the exam curriculum. This article contains notes, tips, and observations from the Istio Mesh Week live streams
Note
Even though I was the one who created the first Istio certification back in 2021, I don't have any knowledge or inside information on what's in this CNCF exam; my guess on what's in the exam is as good as yours.
- Istio installation, upgrade and configuration (Watch on YouTube)
- Istio traffic management (Watch on YouTube)
- Istio resiliency and fault injection (Watch on YouTube)
- Security in Istio and securing workloads (Watch on YouTube)
- Advanced scenarios and troubleshooting Istio (Watch on YouTube)
Understanding IstioOperator resource
apiVersion: install.istio.io/v1alpha1
# Reference: https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1
kind: IstioOperator
spec:
# Configuration profile used as the base for installation
# Other settings you can configure at this level are namespace, hub, revision, tag
profile: demo
# Mesh configuration settings: https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1
meshConfig:
accessLogFile: /dev/stdout
# Individual components you can configure: https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioComponentSetSpec
# Includes base, pilot, cni, ztunnel, ingressGateways, egressGateways, istiodRemote
components:
# pilot: ...
# cni: ...
egressGateways:
# Note that there can be more than one egress/ingress gateway instance.
# To customize a gateway that already is part of the selected profile (E.g., demo in this case)
# make sure you use the default gateway name
- name: istio-egressgateway
# This disables the default egress gateway (i.e., we won't deploy it)
enabled: false
ingressGateways:
# Disable the default ingress gateway
- name: istio-ingressgateway
enabled: false
# Enable a new gateway
- name: peters-gateway
enabled: true
namespace: my-custom-namespace
label:
app: my-label
# Customize the k8s resources: https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#KubernetesResourcesSpec
k8s:
resources:
requests:
cpu: 5m
memory: 20Mi
How traffic comes into the cluster
hello.com
) and a port (80
). These two things "tell" the ingress pod to "listen" for that hostname and port.How to expose services through the Gateway
How to match the traffic
Difference between VirtualService and DestinationRule
Splitting traffic between multiple services/versions/etc.
v1
, v2
deployment). The Service uses a generic label that selects pods from both deployments (e.g. app=helloworld
), while the pods from the versioned deployments also have the version=v1
or version=v2
labels.Note
Replace theversion
labels with whatever you like, want, or need.
...|8080|v1|httpbin...
and ...|8080|v2|httpbin...
and so on. Note the subset names in the string -- this tells Envoy which endpoints (one cluster in Envoy can have multiple endpoints (i.e., hosts, i.e., pod IPs)) to make part of the v2
cluster or part of the v1
cluster and so on. Then, when the matching occurs, and traffic gets routed to one or the other, Envoy points the traffic to one of the pre-defined clusters with the endpoints that are part of that subset.Where are resiliency and fault injection features configured?
What is the difference between authentication and authorization?
What can I do with PeerAuthentication and RequestAuthentication resources?
principal
(PeerAuthentication, service) or a requestPrincipal
(RequestAuthentication, user). These two values, along with IP blocks, namespaces, claims, etc., can be used to create authorization policies in the AuthorizationPolicy resource (specifically in the rules
section).- Which workloads are we applying the policy to? (can be a set of workloads (e.g., using labels), a namespace, or even mesh-wide)
- What is the action? Are we denying (DENY) the requests or allowing (ALLOW) them?
- The actual rules that get evaluated. These get split into three sections:
- From (
from
): where are the requests coming from (e.g., namespace, principal, request principal) - To (
to
): what are the operations we want to apply the action to (e.g., "GET request on /api/blah", "POST and DELETE requests on /hello/*", ...) - When (
when
): conditions when to apply the rule (e.g., "When the issuer of the JWT token == "someone")
- From (
default
namespace only if the request contains a valid JWT token and the user
claim equals ricky
.