Merge remote-tracking branch 'upstream/master' into dev-1.19
This commit is contained in:
Savitha Raghunathan
@@ -65,7 +65,7 @@ This tutorial provides a container image that uses NGINX to echo back all the re
|
||||
|
||||
## Create a Deployment
|
||||
|
||||
A Kubernetes [*Pod*](/docs/concepts/workloads/pods/pod/) is a group of one or more Containers,
|
||||
A Kubernetes [*Pod*](/docs/concepts/workloads/pods/) is a group of one or more Containers,
|
||||
tied together for the purposes of administration and networking. The Pod in this
|
||||
tutorial has only one Container. A Kubernetes
|
||||
[*Deployment*](/docs/concepts/workloads/controllers/deployment/) checks on the health of your
|
||||
|
||||
@@ -20,7 +20,7 @@ weight: 20
|
||||
<div class="row">
|
||||
<div class="col-md-12">
|
||||
<p>
|
||||
A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Learn more about Pods</a>.
|
||||
A Pod is the basic execution unit of a Kubernetes application. Each Pod represents a part of a workload that is running on your cluster. <a href="/docs/concepts/workloads/pods/">Learn more about Pods</a>.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -28,7 +28,7 @@ weight: 10
|
||||
<div class="col-md-8">
|
||||
<h3>Overview of Kubernetes Services</h3>
|
||||
|
||||
<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
|
||||
<p>Kubernetes <a href="/docs/concepts/workloads/pods/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>
|
||||
|
||||
<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
---
|
||||
title: Using Source IP
|
||||
content_type: tutorial
|
||||
mermaid: true
|
||||
min-kubernetes-server-version: v1.5
|
||||
---
|
||||
|
||||
@@ -177,7 +178,7 @@ service/nodeport exposed
|
||||
|
||||
```shell
|
||||
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
|
||||
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
|
||||
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
|
||||
```
|
||||
|
||||
If you're running on a cloud provider, you may need to open up a firewall-rule
|
||||
@@ -206,18 +207,19 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th
|
||||
|
||||
Visually:
|
||||
|
||||
```
|
||||
client
|
||||
\ ^
|
||||
\ \
|
||||
v \
|
||||
node 1 <--- node 2
|
||||
| ^ SNAT
|
||||
| | --->
|
||||
v |
|
||||
endpoint
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph LR;
|
||||
client(client)-->node2[Node 2];
|
||||
node2-->client;
|
||||
node2-. SNAT .->node1[Node 1];
|
||||
node1-. SNAT .->node2;
|
||||
node1-->endpoint(Endpoint);
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
class node1,node2,endpoint k8s;
|
||||
class client plain;
|
||||
{{</ mermaid >}}
|
||||
|
||||
To avoid this, Kubernetes has a feature to
|
||||
[preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip).
|
||||
@@ -261,17 +263,18 @@ This is what happens:
|
||||
|
||||
Visually:
|
||||
|
||||
```
|
||||
client
|
||||
^ / \
|
||||
/ / \
|
||||
/ v X
|
||||
node 1 node 2
|
||||
^ |
|
||||
| |
|
||||
| v
|
||||
endpoint
|
||||
```
|
||||
{{< mermaid >}}
|
||||
graph TD;
|
||||
client --> node1[Node 1];
|
||||
client(client) --x node2[Node 2];
|
||||
node1 --> endpoint(endpoint);
|
||||
endpoint --> node1;
|
||||
|
||||
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
|
||||
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
|
||||
class node1,node2,endpoint k8s;
|
||||
class client plain;
|
||||
{{</ mermaid >}}
|
||||
|
||||
|
||||
|
||||
@@ -324,17 +327,7 @@ deliberately failing health checks.
|
||||
|
||||
Visually:
|
||||
|
||||
```
|
||||
client
|
||||
|
|
||||
lb VIP
|
||||
/ ^
|
||||
v /
|
||||
health check ---> node 1 node 2 <--- health check
|
||||
200 <--- ^ | ---> 500
|
||||
| V
|
||||
endpoint
|
||||
```
|
||||
|
||||
|
||||
You can test this by setting the annotation:
|
||||
|
||||
|
||||
@@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
|
||||
|
||||
|
||||
The preceding command creates a
|
||||
[Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
object and an associated
|
||||
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
object. The ReplicaSet has five
|
||||
[Pods](/docs/concepts/workloads/pods/pod/),
|
||||
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}
|
||||
and an associated
|
||||
{{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}}.
|
||||
The ReplicaSet has five
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}
|
||||
each of which runs the Hello World application.
|
||||
|
||||
1. Display information about the Deployment:
|
||||
|
||||
Reference in New Issue
Block a user