Read what gets installed before installing it: profiles and mesh settings

Goal

You render the four installation profiles with istioctl manifest generate without a cluster and make a table of the component differences, and check that the mesh-wide settings put in with --set meshConfig.… actually appear in the rendered ConfigMap istio. At the end you apply to a real API server a ProxyConfig that overrides just one namespace and see what the schema enforces.

Why it matters

The two decisions that are most expensive to reverse in adopting a mesh are the profile and the mesh-wide configuration. The profile decides what to bring up (whether to have a gateway, whether to go ambient), and the mesh-wide configuration becomes the default for every proxy. If you change just outboundTrafficPolicy.mode to REGISTRY_ONLY, the proxy rejects traffic to unregistered outside destinations. It is different from a security boundary that controls every communication path, but it can affect services immediately. So these values must be read before installing. Fortunately istioctl renders the whole installation result even without a cluster — a manifest is a document you can read as it is, and if you render while changing profiles and compare, what grows and shrinks is clear at a glance. You also confirm here that a wrong value is rejected before it even reaches the cluster.

Steps

Create /root/ist-profiles and save the output of istioctl manifest generate --set profile=default to /root/ist-profiles/default.yaml. Then count the objects in that file by kind and write them in /root/ist-profiles/default-kinds.tsv as <kind>\t<개수> (the placeholders are the kind and the count), in ascending order of kind name.
Save the --set profile=minimal render to /root/ist-profiles/minimal.yaml. And write the objects that are in default but not in minimal in /root/ist-profiles/minimal-missing.tsv, one per line as <kind>|<이름> (the placeholders are the kind and the name), sorted.
Save the --set profile=demo render to /root/ist-profiles/demo.yaml, and write the objects that are only in demo and not in default in /root/ist-profiles/demo-extra.tsv as <kind>|<이름>, sorted.
Use the default profile as it is but add --set values.gateways.istio-ingressgateway.autoscaleMin=3, and save the rendered result to /root/ist-profiles/gw-scaled.yaml. And write the spec.minReplicas value of the HorizontalPodAutoscaler istio-ingressgateway before and after the override in /root/ist-profiles/hpa-before-after.tsv as two lines, before\t<값> and after\t<값> (the placeholder is the value).
Render the minimal profile with four mesh settings added — meshConfig.outboundTrafficPolicy.mode as REGISTRY_ONLY, meshConfig.accessLogFile as /dev/stdout, meshConfig.trustDomain as lab.internal, and meshConfig.defaultConfig.holdApplicationUntilProxyStarts as true. From the render result, extract only the ConfigMap object named istio and save it to /root/ist-profiles/mesh-cm.yaml, and save only the data.mesh string of that ConfigMap to /root/ist-profiles/mesh.yaml.
Get it wrong on purpose three times and collect the error messages in order in /root/ist-profiles/rejected.txt — (1) give meshConfig.outboundTrafficPolicy.mode as BLOCK_ALL to the minimal profile, (2) call a nonexistent profile with --set profile=sidecarless, and (3) give the profile in flag form like --profile=minimal. Include standard error too.
Create the namespace profile-lab and actually apply a ProxyConfig ns-default in it — spec.concurrency is 2, and put ISTIO_META_LAB_TIER: "gold" in spec.environmentVariables. Keep the manifest in /root/ist-profiles/proxyconfig.yaml. Then write ns-negative with concurrency: -1 in /root/ist-profiles/proxyconfig-negative.yaml so that it gets rejected by a server-side trial application, and save that rejection message to /root/ist-profiles/proxyconfig-reject.txt.
In /root/ist-profiles/profile-matrix.tsv, write <프로파일>\t<kind>|<이름>\t<yes|no> (the placeholders are the profile, the kind, the name, and yes or no) — all four profiles default, demo, minimal, and ambient must appear, and all five components Deployment|istiod, Deployment|istio-ingressgateway, Deployment|istio-egressgateway, DaemonSet|ztunnel, and DaemonSet|istio-cni-node must appear (twenty lines). /root/ist-profiles/check-profiles.sh reads this table, re-renders the profiles, prints OK … if it matches and MISMATCH … if not only to standard output, and must end with a non-zero code if even one line is wrong. Save that output to /root/ist-profiles/matrix-result.txt.

Notes

--set profile=<이름> chooses the profile (the placeholder is the profile name). There is no flag called --profile= in 1.24.
To extract objects from the render result, yq -N e '[.kind, .metadata.name] | join("|")' 파일 is convenient (the placeholder is the file).
MeshConfig goes not in a CRD but in the mesh key of the ConfigMap istio.
Common mistake: if you only count the rendered file with grep, you miss document boundaries. Count by document with yq.
Common mistake: mixing values.… and meshConfig.…. The former is chart values and the latter is mesh configuration.
Reference: https://istio.io/v1.24/docs/setup/additional-setup/config-profiles/
Reference: https://istio.io/v1.24/docs/reference/config/istio.mesh.v1alpha1/

First count what the default profile creates

Create /root/ist-profiles and save the output of istioctl manifest generate --set profile=default to /root/ist-profiles/default.yaml. Then count the objects in that file by kind and write them in /root/ist-profiles/default-kinds.tsv as <kind>\t<개수> (the placeholders are the kind and the count), in ascending order of kind name.

The render result is YAML with several documents joined together. You can extract the kind of each document with yq -N e '.kind' 파일 (the placeholder is the file), and if you chain sort and uniq -c onto it, the counts come out. The column separator is a tab.

What exactly disappears when you go down to minimal

Save the --set profile=minimal render to /root/ist-profiles/minimal.yaml. And write the objects that are in default but not in minimal in /root/ist-profiles/minimal-missing.tsv, one per line as <kind>|<이름> (the placeholders are the kind and the name), sorted.

If you extract [.kind, .metadata.name] | join("|") from the two files, tidy each with sort -u, and then compare with comm, the lines present on only one side come out. What disappears is the bundle of objects belonging to one component.

What does demo put on top of default

Save the --set profile=demo render to /root/ist-profiles/demo.yaml, and write the objects that are only in demo and not in default in /root/ist-profiles/demo-extra.tsv as <kind>|<이름> (the placeholders are the kind and the name), sorted.

It is the same method as step 2 but in the opposite direction. For comm, -23 and -13 leave opposite sides. What demo puts on top is a component that gathers outgoing traffic in one place.

Choosing a profile and overriding one value are different knobs

Use the default profile as it is but add --set values.gateways.istio-ingressgateway.autoscaleMin=3, and save the rendered result to /root/ist-profiles/gw-scaled.yaml. And write the spec.minReplicas value of the HorizontalPodAutoscaler istio-ingressgateway before and after the override in /root/ist-profiles/hpa-before-after.tsv as two lines, before\t<값> and after\t<값> (the placeholder is the value).

--set profile= chooses the bundle and --set values.… changes one value inside that bundle. You can pull out the rendered HPA with yq -N e 'select(.kind=="HorizontalPodAutoscaler")' 파일 (the placeholder is the file). For before, you can read it from the file you already extracted in step 1.

The mesh-wide configuration is rendered as one ConfigMap

Render the minimal profile with four mesh settings added — meshConfig.outboundTrafficPolicy.mode as REGISTRY_ONLY, meshConfig.accessLogFile as /dev/stdout, meshConfig.trustDomain as lab.internal, and meshConfig.defaultConfig.holdApplicationUntilProxyStarts as true. From the render result, extract only the ConfigMap object named istio and save it to /root/ist-profiles/mesh-cm.yaml, and save only the data.mesh string of that ConfigMap to /root/ist-profiles/mesh.yaml.

MeshConfig is not a separate CRD but a chunk of YAML that goes in the mesh key of the ConfigMap istio in istio-system. You pull out the object with yq -N e 'select(.kind=="ConfigMap" and .metadata.name=="istio")' - and the string with .data.mesh.

The three things rejected at the render stage

Get it wrong on purpose three times and collect the error messages in order in /root/ist-profiles/rejected.txt — (1) give meshConfig.outboundTrafficPolicy.mode as BLOCK_ALL to the minimal profile, (2) call a nonexistent profile with --set profile=sidecarless, and (3) give the profile in flag form like --profile=minimal. Include standard error too.

All three end with a non-zero code. As in 명령 >> rejected.txt 2>&1 (the placeholder is the command), append standard output and standard error to the same file. The three are caught at different layers — the value's enumeration, the file name, and the command line syntax.

Override the mesh-wide configuration for just one namespace

Create the namespace profile-lab and actually apply a ProxyConfig ns-default in it — spec.concurrency is 2, and put ISTIO_META_LAB_TIER: "gold" in spec.environmentVariables. Keep the manifest in /root/ist-profiles/proxyconfig.yaml. Then write ns-negative with concurrency: -1 in /root/ist-profiles/proxyconfig-negative.yaml so that it gets rejected by a server-side trial application, and save that rejection message to /root/ist-profiles/proxyconfig-reject.txt.

ProxyConfig is a CRD of networking.istio.io/v1beta1, and it overrides MeshConfig's defaultConfig at the namespace or workload level. To ask the API server without applying, use kubectl apply --dry-run=server. The negative-number check is done by the CRD schema, not istioctl.

Build a component table of the four profiles and have it verify itself

In /root/ist-profiles/profile-matrix.tsv, write <프로파일>\t<kind>|<이름>\t<yes|no> (the placeholders are the profile, the kind, the name, and yes or no) — all four profiles default, demo, minimal, and ambient must appear, and all five components Deployment|istiod, Deployment|istio-ingressgateway, Deployment|istio-egressgateway, DaemonSet|ztunnel, and DaemonSet|istio-cni-node must appear (twenty lines). /root/ist-profiles/check-profiles.sh reads this table, re-renders the profiles, prints OK … if it matches and MISMATCH … if not only to standard output, and must end with a non-zero code if even one line is wrong. Save that output to /root/ist-profiles/matrix-result.txt.

If you render the same profile many times it gets slow — render once per profile, keep it in a temporary file, and reuse it. If the script modifies the student's deliverables directly, the values differ when the grader runs it again, so emit only to standard output.