diff --git a/content/en/docs/tutorials/k8s101.md b/content/en/docs/tutorials/k8s101.md deleted file mode 100644 index 0dedd9f3d2253..0000000000000 --- a/content/en/docs/tutorials/k8s101.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -reviewers: -- eparis -- mikedanese -title: Kubernetes 101 -content_template: templates/tutorial ---- - -{{% capture overview %}} - -For Kubernetes 101, we will cover kubectl, Pods, Volumes, and multiple containers. - -{{% /capture %}} - -{{% capture objectives %}} - -* What is `kubectl`. -* Manage a Pod. -* Create and mount a volume. -* Create multiple containers in a Pod. - -{{% /capture %}} - -{{% capture prerequisites %}} - -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* In order for the kubectl usage examples to work, make sure you have an example directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or the latest `.yaml` files located [here](https://github.com/kubernetes/website/tree/master/content/en/docs/tutorials). - -{{% /capture %}} - -{{% capture lessoncontent %}} - -## Kubectl CLI - -The easiest way to interact with Kubernetes is through the kubectl command-line interface. - -For more info about kubectl, including its usage, commands, and parameters, see [Overview of kubectl](/docs/reference/kubectl/overview/). - -For more information about installing and configuring kubectl, see [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/). - -## Pods - -In Kubernetes, a group of one or more containers is called a _Pod_. Containers in a Pod are deployed together, and are started, stopped, and replicated as a group. - -For more information, see [Pods](/docs/concepts/workloads/pods/pod/). - - -#### Pod Definition - -The simplest Pod definition describes the deployment of a single container. For example, an nginx web server Pod might be defined as: - -{{< codenew file="pods/simple-pod.yaml" >}} - -A Pod definition is a declaration of a _desired state_. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and Kubernetes' ensures that the current state matches the desired state. For example, when you create a Pod and declare that the containers in it to be running. If the containers happen not to be running because of a program failure, Kubernetes continues to (re-)create the Pod in order to drive the pod to the desired state. This process continues until you delete the Pod. - -For more information, see [Kubernetes Design Documents and Proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/README.md). - - -#### Pod Management - -Create a Pod containing an nginx server ([simple-pod.yaml](/examples/pods/simple-pod.yaml)): - -```shell -kubectl create -f https://k8s.io/examples/pods/simple-pod.yaml -``` - -List all Pods: - -```shell -kubectl get pods -``` - -On most providers, the Pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox Pod and exec commands on it remotely. For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/). - -If the IP of the Pod is accessible, you can access its http endpoint with wget on port 80: - -```shell -kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')" -u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container -u@busybox$ exit # Exit the busybox container -``` - -```shell -kubectl delete pod busybox # Clean up the pod we created with "kubectl run" -``` - -To delete a Pod named nginx: - -```shell -kubectl delete pod nginx -``` - - -#### Volumes - -That's great for a simple static web server, but what about persistent storage? - -The container file system only lives as long as the container does. So if your app's state needs to survive relocation, reboots, and crashes, you'll need to configure some persistent storage. - -In this example you can create a Redis Pod with a named volume, and a volume mount that defines the path to mount the Volume. - -1. Define a Volume: - - ```yaml - volumes: - - name: redis-storage - emptyDir: {} - ``` - -1. Define a Volume mount within a container definition: - - ```yaml - volumeMounts: -  # name must match the volume name defined in volumes -  - name: redis-storage - # mount path within the container - mountPath: /data/redis - ``` - -Here is an example of Redis Pod definition with a persistent storage volume ([redis.yaml](/examples/pods/storage/redis.yaml)): - -{{< codenew file="pods/storage/redis.yaml" >}} - -Where: - -- The `volumeMounts` `name` is a reference to a specific `volumes` `name`. -- The `volumeMounts` `mountPath` is the path to mount the volume within the container. - -##### Volume Types - -- **EmptyDir**: Creates a new directory that exists as long as the Pod is running on the node, but it can persist across container failures and restarts. -- **HostPath**: Mounts an existing directory on the node's file system. For example (`/var/logs`). - -For more information, see [Volumes](/docs/concepts/storage/volumes/). - - -#### Multiple Containers - -{{< note >}} -**Note:** The examples below are syntactically correct, but some of the images (e.g. kubernetes/git-monitor) don't exist yet. We're working on turning these into working examples. -{{< /note >}} - - -However, often you want to have two different containers that work together. An example of this would be a web server, and a helper job that polls a git repository for new updates: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: www -spec: - containers: - - name: nginx - image: nginx - volumeMounts: - - mountPath: /srv/www - name: www-data - readOnly: true - - name: git-monitor - image: kubernetes/git-monitor - env: - - name: GIT_REPO - value: http://github.com/some/repo.git - volumeMounts: - - mountPath: /data - name: www-data - volumes: - - name: www-data - emptyDir: {} -``` - -Note that we have also added a Volume here. In this case, the Volume is mounted into both containers. It is marked `readOnly` in the web server's case, since it doesn't need to write to the directory. - -Finally, we have also introduced an environment variable to the `git-monitor` container, which allows us to parameterize that container with the particular git repository that we want to track. - -{{% /capture %}} - -{{% capture whatsnext %}} - -Continue on to [Kubernetes 201](/docs/tutorials/k8s201/) or -for a complete application see the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) - -{{% /capture %}} diff --git a/content/en/docs/tutorials/k8s201.md b/content/en/docs/tutorials/k8s201.md deleted file mode 100644 index 3c8b3aa8f962e..0000000000000 --- a/content/en/docs/tutorials/k8s201.md +++ /dev/null @@ -1,266 +0,0 @@ ---- -reviewers: -- janetkuo -- mikedanese -title: Kubernetes 201 -content_template: templates/tutorial ---- - - -{{% capture overview %}} - -For Kubernetes 201, we will pick up where 101 left off and cover some slightly more advanced topics in Kubernetes, related to application productionization, Deployment and scaling. - -If you went through [Kubernetes 101](/docs/tutorials/k8s101/), you learned about kubectl, Pods, Volumes, and multiple containers. - -{{% /capture %}} - -{{% capture objectives %}} - -* Add labels to the Pod. -* Manage a Deployment. -* Manage a Service. -* What is the health checking. - -{{% /capture %}} - -{{% capture prerequisites %}} - -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes). - -{{% /capture %}} - -{{% capture lessoncontent %}} - -## Labels - -Having already learned about Pods and how to create them, you may be struck by an urge to create many, many Pods. Please do! But eventually you will need a system to organize these Pods into groups. The system for achieving this in Kubernetes is Labels. Labels are key-value pairs that are attached to each object in Kubernetes. Label selectors can be passed along with a RESTful `list` request to the apiserver to retrieve a list of objects which match that label selector. - -To add a label, add a labels section under metadata in the Pod definition: - -```yaml - labels: - env: test -``` - -For example, here is the nginx Pod definition with labels ([pod-nginx.yaml](/examples/pods/pod-nginx.yaml)): - -{{< codenew file="pods/pod-nginx.yaml" >}} - -Create the labeled Pod: - -```shell -kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml -``` - -List all Pods with the label `env=test`: - -```shell -kubectl get pods -l env=test -``` - -Delete the Pod by label: - -```shell -kubectl delete pod -l env=test -``` - -For more information, see [Labels](/docs/concepts/overview/working-with-objects/labels/). -They are a core concept used by two additional Kubernetes building blocks: Deployments and Services. - - -## Deployments - -Now that you know how to make awesome, multi-container, labeled Pods and you want to use them to build an application, you might be tempted to just start building a whole bunch of individual Pods, but if you do that, a whole host of operational concerns pop up. For example: how will you scale the number of Pods up or down? How will you roll out a new release? - -The answer to those questions and more is to use a [Deployment](/docs/concepts/workloads/controllers/deployment/) to manage maintaining and updating your running _Pods_. - -A Deployment object defines a Pod creation template (a "cookie-cutter" if you will) and desired replica count. The Deployment uses a label selector to identify the Pods it manages, and will create or delete Pods as needed to meet the replica count. Deployments are also used to manage safely rolling out changes to your running Pods. - -Here is a Deployment that instantiates two nginx Pods: - -{{< codenew file="application/deployment.yaml" >}} - - -### Deployment Management - -Create an nginx Deployment: - -```shell -kubectl create -f https://k8s.io/examples/application/deployment.yaml -``` - -List all Deployments: - -```shell -kubectl get deployment -``` - -List the Pods created by the Deployment: - -```shell -kubectl get pods -l app=nginx -``` - -Upgrade the nginx container from 1.7.9 to 1.8 by changing the Deployment and calling `apply`. The following config -contains the desired changes: - -{{< codenew file="application/deployment-update.yaml" >}} - -```shell -kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml -``` - -Watch the Deployment create Pods with new names and delete the old Pods: - -```shell -kubectl get pods -l app=nginx -``` - -Delete the Deployment by name: - -```shell -kubectl delete deployment nginx-deployment -``` - -For more information, such as how to rollback Deployment changes to a previous version, see [_Deployments_](/docs/concepts/workloads/controllers/deployment/). - - -## Services - -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 Deployment 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 Deployment example ([service.yaml](/examples/service/nginx-service.yaml)): - -{{< codenew file="service/nginx-service.yaml" >}} - - -### Service Management - -Create an nginx Service: - -```shell -kubectl create -f https://k8s.io/examples/service/nginx-service.yaml -``` - -List all services: - -```shell -kubectl get services -``` - -On most providers, the service IPs are not externally accessible. The easiest way to test that the service is working is to create a busybox Pod and exec commands on it remotely. See the [command execution documentation](/docs/user-guide/kubectl-overview/) for details. - -Provided the service IP is accessible, you should be able to access its http endpoint with wget on the exposed port: - -```shell -export SERVICE_IP=$(kubectl get service nginx-service -o go-template='{{.spec.clusterIP}}') -export SERVICE_PORT=$(kubectl get service nginx-service -o go-template='{{(index .spec.ports 0).port}}') -``` - -Check `$SERVICE_IP` and `$SERVICE_PORT`: - -```shell -echo "$SERVICE_IP:$SERVICE_PORT" -``` - -Then, create a busybox Pod: -```shell -kubectl run busybox --generator=run-pod/v1 --image=busybox --restart=Never --tty -i --env "SERVICE_IP=$SERVICE_IP" --env "SERVICE_PORT=$SERVICE_PORT" -u@busybox$ wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run in the busybox container -u@busybox$ exit # Exit the busybox container - -kubectl delete pod busybox # Clean up the pod we created with "kubectl run" - -``` - -The service definition [exposed the Nginx Service](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) as port 8000 (`$SERVICE_PORT`). We can also access the service from a host running Kubernetes using that port: - -```shell -wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run on a Kubernetes host -``` - -(This works on AWS with Weave.) - -To delete the service by name: - -```shell -kubectl delete service nginx-service -``` - -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. - -For more information, see [Services](/docs/concepts/services-networking/service/). - - -## Health Checking - -When I write code it never crashes, right? Sadly the [Kubernetes issues list](https://github.com/kubernetes/kubernetes/issues) indicates otherwise... - -Rather than trying to write bug-free code, a better approach is to use a management system to perform periodic health checking -and repair of your application. That way a system outside of your application itself is responsible for monitoring the -application and taking action to fix it. It's important that the system be outside of the application, since if -your application fails and the health checking agent is part of your application, it may fail as well and you'll never know. -In Kubernetes, the health check monitor is the Kubelet agent. - -### Process Health Checking - -The simplest form of health-checking is just process level health checking. The Kubelet constantly asks the Docker daemon -if the container process is still running, and if not, the container process is restarted. In all of the Kubernetes examples -you have run so far, this health checking was actually already enabled. It's on for every single container that runs in -Kubernetes. - -### Application Health Checking - -However, in many cases this low-level health checking is insufficient. Consider, for example, the following code: - -```go -lockOne := sync.Mutex{} -lockTwo := sync.Mutex{} - -go func() { - lockOne.Lock(); - lockTwo.Lock(); - ... -}() - -lockTwo.Lock(); -lockOne.Lock(); -``` - -This is a classic example of a problem in computer science known as ["Deadlock"](https://en.wikipedia.org/wiki/Deadlock). From Docker's perspective your application is -still operating and 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: - - * HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered success, failure otherwise. See health check examples [here](/docs/user-guide/liveness/). - * Container Exec - The Kubelet will execute a command inside your container. If it exits with status 0 it will be considered a success. See health check examples [here](/docs/user-guide/liveness/). - * 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 any necessary initialization. - -Here is an example config for a Pod with an HTTP health check -([pod-with-http-healthcheck.yaml](/examples/pods/probe/pod-with-http-healthcheck.yaml)): - -{{< codenew file="pods/probe/pod-with-http-healthcheck.yaml" >}} - -And here is an example config for a Pod with a TCP Socket health check -([pod-with-tcp-socket-healthcheck.yaml](/examples/pods/probe/pod-with-tcp-socket-healthcheck.yaml)): - -{{< codenew file="pods/probe/pod-with-tcp-socket-healthcheck.yaml" >}} - -For more information about health checking, see [Container Probes](/docs/user-guide/pod-states/#container-probes). - -{{% /capture %}} - -{{% capture whatsnext %}} - -For a complete application see the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/). - -{{% /capture %}}