github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #2025 from amygdala/cleanup 

a few 'Walkthrough' typo fixes
pull/6/head
Brendan Burns 2014-10-27 21:00:12 -07:00
parent 653d9d70d1 4d9023c887
commit e3fc475b07
2 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
examples/walkthrough/README.md
View File

@ -1,7 +1,7 @@
# Kubernetes 101 - Walkthrough
## Pods
The first atom of Kubernetes is a _pod_. A pod is a collection of containers that are symbiotically group.
The first atom of Kubernetes is a _pod_. A pod is a collection of containers that are symbiotically grouped.
See [pods](../../docs/pods.md) for more details.

16
examples/walkthrough/k8s201.md
View File

@ -71,7 +71,7 @@ selector:
containerPort: 80
```
When created, each service is assigned a unique IP address. This address is tied to the lifespan of the Service, and will not change wile the Service is alive. Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some pod that is a member of the set identified by the label selector in the Service. Services are described in detail [elsewhere](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md).
When created, each service is assigned a unique IP address. This address is tied to the lifespan of the Service, and will not change while the Service is alive. Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some pod that is a member of the set identified by the label selector in the Service. Services are described in detail [elsewhere](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md).
### Health Checking
When I write code it never crashes, right? Sadly the [kubernetes issues list](https://github.com/GoogleCloudPlatform/kubernetes/issues) indicates otherwise...
@ -107,22 +107,22 @@ lockTwo.Lock();
lockOne.Lock();
```
This is a classic example of a problem in computer science known as "Deadlock" from Docker's perspective your application is
This is a classic example of a problem in computer science known as "Deadlock". From Docker's perspective your application is
still operating, the process is still running, but from your application's perspective, your code is locked up, and will never
respond correctly.
To address this problem, Kubernetes supports user implemented application health-checks. These checks are performed by the
kubelet to ensure that your application is operating correctly for a definition of "correctly" that _you_ provide.
Currently there are three types of application health checks that you can choose from
Currently, there are three types of application health checks that you can choose from:
* HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered succes, failure otherwise.
* Container Exec - The Kubelet will execute a command inside your container. If it returns "ok" it will be considered a success
* HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered success, failure otherwise.
* Container Exec - The Kubelet will execute a command inside your container. If it returns "ok" it will be considered a success.
* TCP Socket - The Kubelet will attempt to open a socket to your container. If it can establish a connection, the container is considered healthy, if it can't it is considered a failure.
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 an necessary initialization.
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:
```yaml
@ -148,8 +148,8 @@ desiredState:
# an http probe
httpGet:
path: /_status/healthz
port: 8080
port: 8080
```
### What's next?
For a complete application see the [guestbook example](https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook)
For a complete application see the [guestbook example](https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook).