Application of code include widget, hack curl calls for three file downloads, saas code/pre fixes, comment-out of version drop-down
This commit is contained in:
@@ -102,7 +102,7 @@ volumeMounts:
|
||||
|
||||
Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](/docs/user-guide/walkthrough/pod-redis.yaml)):
|
||||
|
||||
{% include code.html language="yaml" file="pod-redis.yaml" ghlink="https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/user-guide/walkthrough/pod-redis.yaml" %}
|
||||
{% include code.html language="yaml" file="pod-redis.yaml" ghlink="/docs/user-guide/walkthrough/pod-redis.yaml" %}
|
||||
|
||||
Notes:
|
||||
|
||||
|
||||
@@ -23,26 +23,8 @@ labels:
|
||||
```
|
||||
|
||||
For example, here is the nginx pod definition with labels ([pod-nginx-with-label.yaml](/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE pod-nginx-with-label.yaml -->
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
[Download example](/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)
|
||||
<!-- END MUNGE: EXAMPLE pod-nginx-with-label.yaml -->
|
||||
{% include code.html language="yaml" file="pod-nginx-with-label.yaml" ghlink="/docs/user-guide/walkthrough/pod-nginx-with-label.yaml" %}
|
||||
|
||||
Create the labeled pod ([pod-nginx-with-label.yaml](/docs/user-guide/walkthrough/pod-nginx-with-label.yaml)):
|
||||
|
||||
@@ -67,38 +49,9 @@ OK, now you know how to make awesome, multi-container, labeled pods and you want
|
||||
Replication controllers are the objects to answer these questions. A replication controller combines a template for pod creation (a "cookie-cutter" if you will) and a number of desired replicas, into a single Kubernetes object. The replication controller also contains a label selector that identifies the set of objects managed by the replication controller. The replication controller constantly measures the size of this set relative to the desired size, and takes action by creating or deleting pods.
|
||||
|
||||
For example, here is a replication controller that instantiates two nginx pods ([replication-controller.yaml](/docs/user-guide/walkthrough/replication-controller.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE replication-controller.yaml -->
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: nginx-controller
|
||||
spec:
|
||||
replicas: 2
|
||||
# selector identifies the set of Pods that this
|
||||
# replication controller is responsible for managing
|
||||
selector:
|
||||
app: nginx
|
||||
# podTemplate defines the 'cookie cutter' used for creating
|
||||
# new pods when necessary
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
# Important: these labels need to match the selector above
|
||||
# The api server enforces this constraint.
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
[Download example](/docs/user-guide/walkthrough/replication-controller.yaml)
|
||||
<!-- END MUNGE: EXAMPLE replication-controller.yaml -->
|
||||
{% include code.html language="yaml" file="replication-controller.yaml" ghlink="/docs/user-guide/walkthrough/replication-controller.yaml" %}
|
||||
|
||||
|
||||
#### Replication Controller Management
|
||||
|
||||
@@ -128,30 +81,9 @@ For more information, see [Replication Controllers](/docs/user-guide/replication
|
||||
Once you have a replicated set of pods, you need an abstraction that enables connectivity between the layers of your application. For example, if you have a replication controller managing your backend jobs, you don't want to have to reconfigure your front-ends whenever you re-scale your backends. Likewise, if the pods in your backends are scheduled (or rescheduled) onto different machines, you can't be required to re-configure your front-ends. In Kubernetes, the service abstraction achieves these goals. A service provides a way to refer to a set of pods (selected by labels) with a single static IP address. It may also provide load balancing, if supported by the provider.
|
||||
|
||||
For example, here is a service that balances across the pods created in the previous nginx replication controller example ([service.yaml](/docs/user-guide/walkthrough/service.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE service.yaml -->
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nginx-service
|
||||
spec:
|
||||
ports:
|
||||
- port: 8000 # the port that this service should serve on
|
||||
# the container on each pod to connect to, can be a name
|
||||
# (e.g. 'www') or a number (e.g. 80)
|
||||
targetPort: 80
|
||||
protocol: TCP
|
||||
# just like the selector in the replication controller,
|
||||
# but this time it identifies the set of pods to load balance
|
||||
# traffic to.
|
||||
selector:
|
||||
app: nginx
|
||||
```
|
||||
|
||||
[Download example](/docs/user-guide/walkthrough/service.yaml)
|
||||
<!-- END MUNGE: EXAMPLE service.yaml -->
|
||||
{% include code.html language="yaml" file="service.yaml" ghlink="/docs/user-guide/walkthrough/service.yaml" %}
|
||||
|
||||
|
||||
#### Service Management
|
||||
|
||||
@@ -240,34 +172,9 @@ In all cases, if the Kubelet discovers a failure the container is restarted.
|
||||
The container health checks are configured in the `livenessProbe` section of your container config. There you can also specify an `initialDelaySeconds` that is a grace period from when the container is started to when health checks are performed, to enable your container to perform any necessary initialization.
|
||||
|
||||
Here is an example config for a pod with an HTTP health check ([pod-with-http-healthcheck.yaml](/docs/user-guide/walkthrough/pod-with-http-healthcheck.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pod-with-healthcheck
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
# defines the health checking
|
||||
livenessProbe:
|
||||
# an http probe
|
||||
httpGet:
|
||||
path: /_status/healthz
|
||||
port: 80
|
||||
# length of time to wait for a pod to initialize
|
||||
# after pod startup, before applying health checking
|
||||
initialDelaySeconds: 30
|
||||
timeoutSeconds: 1
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
[Download example](/docs/user-guide/walkthrough/pod-with-http-healthcheck.yaml)
|
||||
<!-- END MUNGE: EXAMPLE pod-with-http-healthcheck.yaml -->
|
||||
{% include code.html language="yaml" file="pod-with-http-healthcheck.yaml" ghlink="/docs/user-guide/walkthrough/pod-with-http-healthcheck.yaml" %}
|
||||
|
||||
|
||||
For more information about health checking, see [Container Probes](/docs/user-guide/pod-states/#container-probes).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user