Like any other certification, the purpose of ICA is to validate your knowledge of Istio. It is a great way to show your current or future employer you have the skills and expertise to work with Istio.
You can already purchase the certification exam, but you will be able to take it in November 2023, so keep this in mind as you read this blog post.
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.
CNCF publishes an exam curriculum, so we have a high-level idea of different topics that one should review and prepare for. For actual details about the exam, make sure you read the information on the frequently asked questions page and the ICA exam page.
As we saw the news, we (my coworkers Marino, Alessandro, and me) decided to create a series of live streams called Mesh Week. The idea behind these sessions was that anyone interested in Istio and preparing for the Istio Certified Associate exam can use them.
We did five live streams, going through the curriculum and covering the following topics:
Here are my notes, tips, and observations from these sessions.
If there were only one thing to take away from the Istio installation session, it would be understanding different configuration pieces and where to configure them.
Here's a sample IstioOperator resource that shows you the sections and points to reference documentation:
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
Using the Gateway resource (that configures the ingress/egress gateway (the actual pod)) and a combination of a hostname (e.g., hello.com) and a port (80). These two things "tell" the ingress pod to "listen" for that hostname and port.
The routing rules that "tell" Istio where to route the traffic are all in the VirtualService. To expose a Kubernetes service through the Gateway, you attach the gateway to the VirtualService. The Gateway only defines the ports, host names, and TLS configuration you want the gateway to listen on, while the VirtualService defines the routing rules.
You can match the traffic on URI paths, headers, query parameters, gateways, etc... The matching acts similarly to the "if-else" statements where the "if" portion is applied if the match is true, otherwise the remaining rules get processed. In most cases, you can match the values exactly, by prefix, or using a Regex.
In VirtualService, you match the traffic, define where it gets routed, add/remove headers if needed, while with the DestinationRule, you control the configuration on the endpoints (i.e., collection of target pod IPs) side. I.e., you can control the load-balancing algorithm to be used when selecting one of the destinations, TLS configuration, circuit breakers, etc.
You'll have a single Kubernetes Service and one or more Deployments (e.g., 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 the
versionlabels with whatever you like, want, or need.
To tell Istio about these different versions, you create named subsets in the DestinationRule. Then, to route to one or the other subset, you reference it in the VirtualService.
The way this works behind the scenes (i.e., Envoy) is that there are different clusters (an Envoy concept) configured for each subset. For example, a cluster named ...|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.
I've explained how this works with a demo here.
Any timeouts, retries, and fault injection is configured in the VirtualService resource. While things like circuit breakers and outlier detection are configured in the DestinationRule.
In the security stream, we talked about the difference between authentication ("Is a credential valid and trusted?") and authorization ("Is a validated credential allowed to perform an action on an object?").
We also introduced the resources in Istio that manage authentication and authorization.
The two resources that deal with authentication in Istio are the PeerAuthentication and the RequestAuthentication. The former deals with services, while the latter deals with users and end-user authentication.
The "result" of both resources is either a 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).
You can use the AuthorizationPolicy to configure and define the following:
from): where are the requests coming from (e.g., namespace, principal, request principal)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): conditions when to apply the rule (e.g., "When the issuer of the JWT token == "someone")The nice thing about the AuthorizationPolicy is that you can combine rules involving services and end-users. For example, you can allow all requests from the default namespace only if the request contains a valid JWT token and the user claim equals ricky.
Thanks to everyone who showed up and said Hello during the live streams. I hope you found them helpful and that you learned something new. If you decide to take on the Istio Certified Associate, let me know how it goes!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。