mirror of https://github.com/istio/istio.io.git
Improve the readability of the pod requirements. (#3633)
Signed-off-by: rcaballeromx <grca@google.com>
This commit is contained in:
Rigs Caballero
istio-bot
parent
7313fcfa1d
commit
71e3462e30
|
|
@ -5,37 +5,57 @@ weight: 5
|
|||
keywords: [kubernetes,sidecar,sidecar-injection]
|
||||
---
|
||||
|
||||
To be a part of the service mesh, pods and services in a Kubernetes
|
||||
To be a part of an Istio service mesh, pods and services in a Kubernetes
|
||||
cluster must satisfy the following requirements:
|
||||
|
||||
* _**Named service ports**:_ Service ports must be named. The port names must be of
|
||||
the form `<protocol>[-<suffix>]` with `grpc`, `http`, `http2`, `https`, `mongo`, `redis`, `tcp`, `tls` or `udp`
|
||||
as the `<protocol>` in order to take advantage of Istio's routing features.
|
||||
For example, `name: http2-foo` or `name: http` are valid port names, but
|
||||
`name: http2foo` is not. If the port name does not begin with a recognized
|
||||
prefix or if the port is unnamed, traffic on the port will be treated as
|
||||
plain TCP traffic (unless the port [explicitly](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)
|
||||
uses `Protocol: UDP` to signify a UDP port).
|
||||
- **Named service ports**: Service ports must be named. The port name key/value
|
||||
pairs must have the following syntax: `name: <protocol>[-<suffix>]`. To take
|
||||
advantage of Istio's routing features, replace `<protocol>` with one of the
|
||||
following values:
|
||||
|
||||
* _**Pod ports**:_ Pods must include an explicit list of ports each container will listen on.
|
||||
Use a `containerPort` in the container spec for each port. Any unlisted ports will bypass the Istio
|
||||
Proxy.
|
||||
- `grpc`
|
||||
- `http`
|
||||
- `http2`
|
||||
- `https`
|
||||
- `mongo`
|
||||
- `redis`
|
||||
- `tcp`
|
||||
- `tls`
|
||||
- `udp`
|
||||
|
||||
* _**Service association**:_ A pod must belong to at least one [Kubernetes service](https://kubernetes.io/docs/concepts/services-networking/service/),
|
||||
even if it does NOT expose any port.
|
||||
For example, `name: http2-foo` or `name: http` are valid port names, but
|
||||
`name: http2foo` is not. If the port name does not begin with a recognized
|
||||
prefix or if the port is unnamed, traffic on the port is treated as
|
||||
plain TCP traffic unless the port [explicitly](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)
|
||||
uses `Protocol: UDP` to signify a UDP port.
|
||||
|
||||
- **Pod ports**: Pods must include an explicit list of the ports each
|
||||
container listens on. Use a `containerPort` configuration in the container
|
||||
specification for each port. Any unlisted ports bypass the Istio proxy.
|
||||
|
||||
- **Service association**: A pod must belong to at least one Kubernetes
|
||||
service even if the pod does NOT expose any port.
|
||||
If a pod belongs to multiple [Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/),
|
||||
the services cannot use the same port number for different protocols, for instance HTTP and TCP.
|
||||
the services cannot use the same port number for different protocols, for
|
||||
instance HTTP and TCP.
|
||||
|
||||
* _**Deployments with app and version labels**:_ It is recommended that pods deployed using
|
||||
the Kubernetes `Deployment` have an explicit `app` label and `version` label in the
|
||||
deployment specification. Each deployment specification should have a
|
||||
distinct `app` label with a value indicating something meaningful, with `version`
|
||||
indicating the version of the app that the particular deployment corresponds to. The
|
||||
`app` label is used to add contextual information in distributed
|
||||
tracing. The `app` and `version` labels are also used to add contextual information
|
||||
in the metric telemetry collected by Istio.
|
||||
- **Deployments with app and version labels**: We recommend adding an explicit
|
||||
`app` label and `version` label to deployments. Add the labels to the
|
||||
deployment specification of pods deployed using the Kubernetes `Deployment`.
|
||||
The `app` and `version` labels add contextual information to the metrics and
|
||||
telemetry Istio collects.
|
||||
|
||||
* _**Application UIDs**_: Do **not** run applications as a user with the user ID (UID) value of **1337**.
|
||||
- The `app` label: Each deployment specification should have a distinct
|
||||
`app` label with a meaningful value. The `app` label is used to add
|
||||
contextual information in distributed tracing.
|
||||
|
||||
* _**`NET_ADMIN` capability**:_ If pod security policies are enforced in your cluster and unless you use the [Istio CNI Plugin](/docs/setup/kubernetes/additional-setup/cni/), your pods must have the `NET_ADMIN` capability allowed.
|
||||
See [Required Pod Capabilities](/help/ops/setup/required-pod-capabilities/).
|
||||
- The `version` label: This label indicates the version of the application
|
||||
corresponding to the particular deployment.
|
||||
|
||||
- **Application UIDs**: Ensure your pods do **not** run applications as a user
|
||||
with the user ID (UID) value of **1337**.
|
||||
|
||||
- **`NET_ADMIN` capability**: If your cluster enforces pod security policies,
|
||||
pods must allow the `NET_ADMIN` capability. If you use the [Istio CNI Plugin](/docs/setup/kubernetes/additional-setup/cni/),
|
||||
this requirement no longer applies. To learn more about the `NET_ADMIN`
|
||||
capability, visit [Required Pod Capabilities](/help/ops/setup/required-pod-capabilities/).
|
||||
|
|
|
|||
Loading…
Reference in New Issue