mirror of https://github.com/istio/istio.io.git
7 lines
3.5 KiB
XML
7 lines
3.5 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Installation and Configuration on Istio</title><link>/v1.3/docs/ops/setup/</link><description>Recent content in Installation and Configuration on Istio</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="/v1.3/docs/ops/setup/feed.xml" rel="self" type="application/rss+xml"/><item><title>Automatic Sidecar Injection</title><link>/v1.3/docs/ops/setup/injection-concepts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/ops/setup/injection-concepts/</guid><description>Automatic sidecar injection adds the sidecar proxy into user-created pods. It uses a MutatingWebhook to append the sidecar’s containers and volumes to each pod’s template spec during creation time. Injection can be scoped to particular sets of namespaces using the webhooks namespaceSelector mechanism. Injection can also be enabled and disabled per-pod with an annotation.
|
||
Whether or not a sidecar is injected depends on three pieces of configuration and two security rules:</description></item><item><title>Required Pod Capabilities</title><link>/v1.3/docs/ops/setup/required-pod-capabilities/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/ops/setup/required-pod-capabilities/</guid><description>If pod security policies are enforced in your cluster and unless you use Istio CNI Plugin, your pods must have the NET_ADMIN capability allowed. The initialization containers of the Envoy proxies require this capability. To check which capabilities are allowed for your pods, check if their service account can use a pod security policy that allows the NET_ADMIN capability.
|
||
If you don&rsquo;t specify a service account in your pods&rsquo; deployment, the pods run as the default service account in their deployment&rsquo;s namespace.</description></item><item><title>Dynamic Admission Webhooks Overview</title><link>/v1.3/docs/ops/setup/webhook/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/ops/setup/webhook/</guid><description>From Kubernetes mutating and validating webhook mechanisms:
|
||
Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, validating admission webhook and mutating admission webhook. With validating admission webhooks, you may reject requests to enforce custom admission policies. With mutating admission webhooks, you may change requests to enforce custom defaults. Istio uses ValidatingAdmissionWebhooks for validating Istio configuration and MutatingAdmissionWebhooks for automatically injecting the sidecar proxy into user pods.</description></item><item><title>Configuration Validation Webhook</title><link>/v1.3/docs/ops/setup/validation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/ops/setup/validation/</guid><description>Galley&rsquo;s configuration validation ensures user authored Istio configuration is syntactically and semantically valid. It uses a Kubernetes ValidatingWebhook. The istio-galley ValidatingWebhookConfiguration has two webhooks.
|
||
pilot.validation.istio.io - Served on path /admitpilot and is responsible for validating configuration consumed by Pilot (e.g. VirtualService, Authentication).
|
||
mixer.validation.istio.io - Served on path /admitmixer and is responsible for validating configuration consumed by Mixer.
|
||
Both webhooks are implemented by the istio-galley service on port 443.</description></item></channel></rss> |