- Written by Peter Jausovec
- Understanding IstioOperator resource
- How traffic comes into the cluster
- How to expose services through the Gateway
- How to match the traffic
- Difference between VirtualService and DestinationRule
- Splitting traffic between multiple services/versions/etc.
- 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?
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.
v2deployment). 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
versionlabels with whatever you like, want, or need.
...|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
v2cluster or part of the
v1cluster 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
- 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 (
defaultnamespace only if the request contains a valid JWT token and the