-{% for card in page.cards %}{% if card.title %}
-
-
{{card.title}}
-
{% if card.image %}{% endif %}{{card.description}}
-
-{% endif %}{% endfor %}
-
-
-{% else %}
-
-### ERROR: You must define "cards" front-matter YAML
-{: style="color:red" }
-
-This template requires that you insert YAML at the top of your document
-that defines the "cards" you'd like to display on the page. The cards will
-render in clickable boxes.
-
-To get rid of this message and take advantage of this template, define `cards`:
-
-```yaml
----
-cards:
-- progression: no
-- card:
- title: Mean Stack
- image: /docs/meanstack/image_0.png
- description: Lorem ipsum dolor it verberum.
-- card:
- title: Guestbook + Redis
- image: /images/docs/redis.svg
- description: Lorem ipsum dolor it verberum.
-- card:
- title: Cloud Native Cassandra
- image: /images/docs/cassandra.svg
- description: Lorem ipsum dolor it verberum.
-- card:
- title: WordPress + MySQL
- image: /images/docs/wordpress.svg
- description: Lorem ipsum dolor it verberum.
----
-```
-
-**Note:** If `progression` is set to `yes` then a "Start Here!" icon will be
-placed on the first card and arrows suggesting linear reading will be overlayed
-between the other cards, telling the reader that they should explore the content
-in a certain order.
-
-{% endif %}
diff --git a/_layouts/docwithnav.html b/_layouts/docwithnav.html
index aacead888e..b7da71eb57 100755
--- a/_layouts/docwithnav.html
+++ b/_layouts/docwithnav.html
@@ -28,7 +28,6 @@
diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md
deleted file mode 100644
index b47ac1150a..0000000000
--- a/docs/getting-started-guides/meanstack.md
+++ /dev/null
@@ -1,447 +0,0 @@
----
-title: MEAN stack on Google Cloud Platform
----
-
-**By: Sandeep Dinesh** - _July 29, 2015_
-
-
-
-In [a recent post](http://blog.sandeepdinesh.com/2015/07/running-mean-web-application-in-docker.html), I talked about running a MEAN stack with [Docker Containers.](http://docker.com/)
-
-Manually deploying Containers is all fine and dandy, but is rather fragile and clumsy. What happens if the app crashes? How can the app be updated? Rolled back?
-
-Thankfully, there is a system we can use to manage our containers in a cluster environment called Kubernetes. Even better, Google has a managed version of Kubernetes called [Google Container Engine](https://cloud.google.com/container-engine/) so you can get up and running in minutes.
-
-* TOC
-{:toc}
-
-## The Basics of Using Kubernetes
-
-Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes.
-
-* Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly.
-* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database.
-* Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones.
-* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services.
-
-
-## Step 1: Creating the Container
-
-In my previous post, I used off-the-shelf containers to keep things simple.
-
-I had a stock MongoDB container and a stock Node.js container. The Mongo container ran fine without any modification. However, I had to manually enter the Node container to pull and run the code. Obviously this isn't ideal in Kubernetes land, as you aren't supposed to log into your servers!
-
-Instead, you have to build a custom container that has the code already inside it and runs automatically.
-
-To do this, you need to use more Docker. Make sure you have the latest version installed for the rest of this tutorial.
-
-Getting the code:
-
-Before starting, let's get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial.
-
-```shell
-$ git clone https://github.com/ijason/NodeJS-Sample-App.git app
-$ mv app/EmployeeDB/* app/
-$ sed -i -- 's/localhost/mongo/g' ./app/app.js
-```
-
-This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it's easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy.
-
-Building the Docker image:
-
-First, you need a `Dockerfile`. This is basically the list of instructions Docker uses to build a container image.
-
-Here is the `Dockerfile` for the web server:
-
-```shell
-FROM node:4.4
-
-RUN mkdir -p /usr/src/app
-WORKDIR /usr/src/app
-COPY ./app/ ./
-RUN npm install
-
-CMD ["node", "app.js"]
-```
-
-A `Dockerfile` is pretty self-explanatory, and this one is dead simple.
-
-First, it uses the official Node.js LTS image as the base image.
-
-Then, it creates a folder to store the code, `cd`s into that directory, copies the code in, and installs the dependencies with npm.
-
-Finally, it specifies the command Docker should run when the container starts, which is to start the app.
-
-
-## Step 2: Building our Container
-
-Right now, the directory should look like this:
-
-```shell
-$ ls
-
-Dockerfile app
-```
-
-Let's build.
-
-```shell
-$ docker build -t myapp .
-```
-
-This will build a new Docker image for your app. This might take a few minutes as it is downloading and building everything.
-
-After that is done, test it out:
-
-```shell
-$ docker run myapp
-```
-
-At this point, you should have a server running on `http://localhost:3000` (or wherever Docker tells you). The website will error out as there is no database running, but we know it works!
-
-
-
-
-## Step 3: Pushing our Container
-
-Now you have a custom Docker image, you have to actually access it from the cloud.
-
-As we are going to be using the image with Google Container Engine, the best place to push the image is the [Google Container Registry](https://cloud.google.com/tools/container-registry/). The Container Registry is built on top of [Google Cloud Storage](https://cloud.google.com/storage/), so you get the advantage of scalable storage and very fast access from Container Engine.
-
-First, make sure you have the latest version of the [Google Cloud SDK installed](https://cloud.google.com/sdk/).
-
-[Windows users click here.](https://dl.google.com/dl/cloudsdk/release/GoogleCloudSDKInstaller.exe)
-
-For Linux/Mac:
-
-```shell
-$ curl https://sdk.cloud.google.com | bash
-```
-
-Then, make sure you log in and update.
-
-```shell
-$ gcloud auth login
-$ gcloud components update
-```
-
-You're ready to push your container live, but you'll need a destination. Create a Project in [the Google Cloud Platform Console](https://console.developers.google.com/), and leave it blank. Use the Project ID below, and push your project live.
-
-```shell
-$ docker tag myapp gcr.io//myapp
-$ gcloud docker push gcr.io//myapp
-```
-
-After some time, it will finish. You can check the console to see the container has been pushed up.
-
-
-
-
-## **Step 4: Creating the Cluster**
-
-So now you have the custom container, let's create a cluster to run it.
-
-Currently, a cluster can be as small as one machine to as big as 100 machines. You can pick any machine type you want, so you can have a cluster of a single `f1-micro` instance, 100 `n1-standard-32` instances (3,200 cores!), and anything in between.
-
-For this tutorial I'm going to use the following:
-
-* Create a cluster named `mean-cluster`
-* Give it a size of 2 nodes
-* Machine type will be `n1-standard-1`
-* Zone will be `us-central-1f` (Use a zone close to you)
-
-There are two ways to create this cluster. Take your pick.
-
-**Command Line:**
-
-```shell
-$ gcloud beta container \
- --project "" \
- clusters create "mean-cluster" \
- --zone "us-central1-f" \
- --machine-type "n1-standard-1" \
- --num-nodes "2" \
- --network "default"
-```
-
-**GUI:**
-
-
-
-After a few minutes, you should see this in the console.
-
-
-
-
-## **Step 5: Creating the Database Service**
-
-Three things need to be created:
-
-1. Persistent Disk to store the data (pods are ephemeral, so we shouldn't save data locally)
-2. Deployment running MongoDB
-3. Service mapping to that Deployment
-
-To create the disk, run this:
-
-```shell
-$ gcloud compute disks create \
- --project "" \
- --zone "us-central1-f" \
- --size 200GB \
- mongo-disk
-```
-
-Pick the same zone as your cluster and an appropriate disk size for your application.
-
-Now, we need to create a Deployment that will run the database. I'm using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically.
-
-### `db-deployment.yml`
-
-```yaml
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
- name: mongo-deployment
-spec:
- replicas: 1
- template:
- metadata:
- labels:
- name: mongo
- spec:
- containers:
- - image: mongo
- name: mongo
- ports:
- - name: mongo
- containerPort: 27017
- hostPort: 27017
- volumeMounts:
- - name: mongo-persistent-storage
- mountPath: /data/db
- volumes:
- - name: mongo-persistent-storage
- gcePersistentDisk:
- pdName: mongo-disk
- fsType: ext4
-
-```
-
-We call the deployment `mongo-deployment`, specify one replica, and open the appropriate ports. The image is `mongo`, which is the off the shelf MongoDB image.
-
-The `volumes` section creates the volume for Kubernetes to use. There is a Google Container Engine-specific `gcePersistentDisk` section that maps the disk we made into a Kubernetes volume, and we mount the volume into the `/data/db` directory (as described in the MongoDB Docker documentation)
-
-Now we have the Deployment, let's create the Service:
-
-### `db-service.yml`
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- labels:
- name: mongo
- name: mongo
-spec:
- ports:
- - port: 27017
- targetPort: 27017
- selector:
- name: mongo
-```
-
-Again, pretty simple stuff. We "select" the mongo Deployment to be served, open up the ports, and call the service `mongo`.
-
-This is just like the "link" command line option we used with Docker in my previous post. Instead of connecting to `localhost`, we connect to `mongo`, and Kubernetes redirects traffic to the mongo service!
-
-At this point, the local directory looks like this:
-
-```shell
-$ ls
-
-Dockerfile
-app
-db-deployment.yml
-db-service.yml
-```
-
-## Step 6: Running the Database
-
-First, let's "log in" to the cluster
-
-```shell
-$ gcloud container clusters get-credentials mean-cluster
-```
-
-Now create the Deployment.
-
-```shell
-$ kubectl create -f db-deployment.yml
-```
-
-And the Service.
-
-```shell
-$ kubectl create -f db-service.yml
-```
-
-`kubectl` is the Kubernetes command line tool (automatically installed with the Google Cloud SDK). We are just creating the resources specified in the files.
-
-At this point, the database is spinning up! You can check progress with the following command:
-
-```shell
-$ kubectl get pods
-```
-
-Once you see the mongo pod in running status, we are good to go!
-
-```shell
-$ kubectl get pods
-
-NAME READY REASON RESTARTS AGE
-mongo-deployment-xxxx 1/1 Running 0 3m
-```
-
-
-## Step 7: Creating the Web Server
-
-Now the database is running, let's start the web server.
-
-We need two things:
-
-1. Deployment to spin up and down web server pods
-2. Service to expose our website to the interwebs
-
-Let's look at the Deployment configuration:
-
-### `web-deployment.yml`
-
-```yaml
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
- name: web-deployment
-spec:
- replicas: 2
- template:
- metadata:
- labels:
- name: web
- spec:
- containers:
- - image: gcr.io//myapp
- name: web
- ports:
- - name: http-server
- containerPort: 3000
-
-```
-
-Here, we create a deployment called `web-deployment`, and we tell it to create two replicas. Replicas of what you ask? You may notice the `template` section looks just like a Pod configuration, and that's because it is. We are creating a Pod with our custom Node.js container and exposing port 3000.
-
-
-Now for the Service
-
-### `web-service.yml`
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
- name: web
- labels:
- name: web
-spec:
- type: LoadBalancer
- ports:
- - port: 80
- targetPort: 3000
- protocol: TCP
- selector:
- name: web
-```
-
-Notice two things here:
-
-1. The type is *LoadBalancer*. This is a cool feature that will make Google Cloud Platform create an external network load balancer automatically for this service!
-2. We map external port 80 to the internal port 3000, so we can serve HTTP traffic without messing with Firewalls.
-
-At this point, the local directory looks like this
-
-```shell
-$ ls
-
-Dockerfile
-app
-db-deployment.yml
-db-service.yml
-web-service.yml
-web-deployment.yml
-```
-
-
-## Step 8: Running the Web Server
-
-Create the Deployment.
-
-```shell
-$ kubectl create -f web-deployment.yml
-```
-
-And the Service.
-
-```shell
-$ kubectl create -f web-service.yml
-```
-
-And check the status.
-
-```shell
-$ kubectl get pods
-```
-
-Once you see the web pods in running status, we are good to go!
-
-```shell
-$ kubectl get pods
-
-NAME READY REASON RESTARTS AGE
-mongo-deployment-xxxx 1/1 Running 0 4m
-web-deployment-xxxx 1/1 Running 0 1m
-web-deployment-xxxx 1/1 Running 0 1m
-```
-
-
-## Step 9: Accessing the App
-
-At this point, everything is up and running. The architecture looks something like this:
-
-{: style="max-width:25%"}
-
-By default, port 80 should be open on the load balancer. In order to find the IP address of our app, run this command:
-
-```shell
-$ gcloud compute forwarding-rules list
-
-NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
-abcdef us-central1 104.197.XXX.XXX TCP us-xxxx
-```
-
-If you go to the IP address listed, you should see the app up and running!
-
-
-
-And the Database works!
-
-
-
-
-#### **Final Thoughts**
-
-By using Container Engine and Kubernetes, we have a very robust, container based MEAN stack running in production.
-
-[In another post](https://medium.com/google-cloud/mongodb-replica-sets-with-kubernetes-d96606bd9474#.e93x7kuq5), I cover how to setup a MongoDB replica set. This is very important for running in production.
-
-Hopefully I can do some more posts about advanced Kubernetes topics such as changing the cluster size and number of Node.js web server replicas, using different environments (dev, staging, prod) on the same cluster, and doing rolling updates.
-
-Thanks to [Mark Mandel](https://medium.com/@markmandel), [Aja Hammerly](https://medium.com/@thagomizer), and [Jack Wilber](https://medium.com/@jack.g.wilber). [Some rights reserved](http://creativecommons.org/licenses/by/4.0/) by the author.
diff --git a/docs/samples.md b/docs/samples.md
deleted file mode 100644
index e22c7698cb..0000000000
--- a/docs/samples.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-assignees:
-- bgrant0607
-title: Samples
----
-
-We have a wide variety of samples to choose from.
-
-## Recently updated samples
-
-The Kubernetes team is highlighting these samples as being the most up-to-date. Active upkeep is being done or has recently been done
-on these samples to ensure they are high quality and work on Kubernetes {{page.version}}.
-
-
diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md
index 6a750a37bf..378c06358a 100644
--- a/docs/tutorials/index.md
+++ b/docs/tutorials/index.md
@@ -1,5 +1,8 @@
---
title: Tutorials
+redirect_from:
+- "/docs/samples/"
+- "/docs/samples.html"
---
This section of the Kubernetes documentation contains tutorials.
@@ -17,6 +20,8 @@ each of which has a sequence of steps.
* [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/)
+* [Example: PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/)
+
* [Using a Service to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address-service/)
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
@@ -29,6 +34,10 @@ each of which has a sequence of steps.
* [Running a Replicated Stateful Application](/docs/tutorials/stateful-application/run-replicated-stateful-application/)
+* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
+
+* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
+
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
#### Connecting Applications
diff --git a/docs/tutorials/stateful-application/cassandra.md b/docs/tutorials/stateful-application/cassandra.md
new file mode 100644
index 0000000000..9a006b09db
--- /dev/null
+++ b/docs/tutorials/stateful-application/cassandra.md
@@ -0,0 +1,859 @@
+---
+title: "Example: Deploying Cassandra with Stateful Sets"
+---
+
+## Table of Contents
+
+ - [Prerequisites](#prerequisites)
+ - [Cassandra Docker](#cassandra-docker)
+ - [Quickstart](#quickstart)
+ - [Step 1: Create a Cassandra Headless Service](#step-1-create-a-cassandra-headless-service)
+ - [Step 2: Use a StatefulSet to create Cassandra Ring](#step-2-use-a-statefulset-to-create-cassandra-ring)
+ - [Step 3: Validate and Modify The Cassandra StatefulSet](#step-3-validate-and-modify-the-cassandra-statefulset)
+ - [Step 4: Delete Cassandra StatefulSet](#step-4-delete-cassandra-statefulset)
+ - [Step 5: Use a Replication Controller to create Cassandra node pods](#step-5-use-a-replication-controller-to-create-cassandra-node-pods)
+ - [Step 6: Scale up the Cassandra cluster](#step-6-scale-up-the-cassandra-cluster)
+ - [Step 7: Delete the Replication Controller](#step-7-delete-the-replication-controller)
+ - [Step 8: Use a DaemonSet instead of a Replication Controller](#step-8-use-a-daemonset-instead-of-a-replication-controller)
+ - [Step 9: Resource Cleanup](#step-9-resource-cleanup)
+ - [Seed Provider Source](#seed-provider-source)
+
+The following document describes the development of a _cloud native_
+[Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. When we say
+_cloud native_, we mean an application which understands that it is running
+within a cluster manager, and uses this cluster management infrastructure to
+help implement the application. In particular, in this instance, a custom
+Cassandra `SeedProvider` is used to enable Cassandra to dynamically discover
+new Cassandra nodes as they join the cluster.
+
+This example also uses some of the core components of Kubernetes:
+
+- [_Pods_](/docs/user-guide/pods)
+- [ _Services_](/docs/user-guide/services)
+- [_Replication Controllers_](/docs/user-guide/replication-controller)
+- [_Stateful Sets_](/docs/concepts/workloads/controllers/statefulset/)
+- [_Daemon Sets_](/docs/admin/daemons)
+
+## Prerequisites
+
+This example assumes that you have a Kubernetes version >=1.2 cluster installed and running,
+and that you have installed the [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
+command line tool somewhere in your path. Please see the
+[getting started guides](https://kubernetes.io/docs/getting-started-guides/)
+for installation instructions for your platform.
+
+This example also has a few code and configuration files needed. To avoid
+typing these out, you can `git clone` the Kubernetes repository to your local
+computer.
+
+## Cassandra Docker
+
+The pods use the [```gcr.io/google-samples/cassandra:v12```](image/Dockerfile)
+image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
+The docker is based on `debian:jessie` and includes OpenJDK 8. This image
+includes a standard Cassandra installation from the Apache Debian repo. Through the use of environment variables you are able to change values that are inserted into the `cassandra.yaml`.
+
+| ENV VAR | DEFAULT VALUE |
+| ------------- |:-------------: |
+| CASSANDRA_CLUSTER_NAME | 'Test Cluster' |
+| CASSANDRA_NUM_TOKENS | 32 |
+| CASSANDRA_RPC_ADDRESS | 0.0.0.0 |
+
+## Quickstart
+
+If you want to jump straight to the commands we will run,
+here are the steps:
+
+```sh
+#
+# StatefulSet
+#
+
+# clone the example repository
+git clone https://github.com/kubernetes/examples
+cd examples
+
+# create a service to track all cassandra statefulset nodes
+kubectl create -f cassandra/cassandra-service.yaml
+
+# create a statefulset
+kubectl create -f cassandra/cassandra-statefulset.yaml
+
+# validate the Cassandra cluster. Substitute the name of one of your pods.
+kubectl exec -ti cassandra-0 -- nodetool status
+
+# cleanup
+grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}') \
+ && kubectl delete statefulset,po -l app=cassandra \
+ && echo "Sleeping $grace" \
+ && sleep $grace \
+ && kubectl delete pvc -l app=cassandra
+
+#
+# Resource Controller Example
+#
+
+# create a replication controller to replicate cassandra nodes
+kubectl create -f cassandra/cassandra-controller.yaml
+
+# validate the Cassandra cluster. Substitute the name of one of your pods.
+kubectl exec -ti cassandra-xxxxx -- nodetool status
+
+# scale up the Cassandra cluster
+kubectl scale rc cassandra --replicas=4
+
+# delete the replication controller
+kubectl delete rc cassandra
+
+#
+# Create a DaemonSet to place a cassandra node on each kubernetes node
+#
+
+kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false
+
+# resource cleanup
+kubectl delete service -l app=cassandra
+kubectl delete daemonset cassandra
+```
+
+## Step 1: Create a Cassandra Headless Service
+
+A Kubernetes _[Service](/docs/user-guide/services)_ describes a set of
+[_Pods_](/docs/user-guide/pods) that perform the same task. In
+Kubernetes, the atomic unit of an application is a Pod: one or more containers
+that _must_ be scheduled onto the same host.
+
+The Service is used for DNS lookups between Cassandra Pods, and Cassandra clients
+within the Kubernetes Cluster.
+
+Here is the service description:
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ labels:
+ app: cassandra
+ name: cassandra
+spec:
+ clusterIP: None
+ ports:
+ - port: 9042
+ selector:
+ app: cassandra
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-service.yaml)
+
+
+Create the service for the StatefulSet:
+
+
+```console
+$ kubectl create -f cassandra/cassandra-service.yaml
+```
+
+The following command shows if the service has been created.
+
+```console
+$ kubectl get svc cassandra
+```
+
+The response should be like:
+
+```console
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+cassandra None 9042/TCP 45s
+```
+
+If an error is returned the service create failed.
+
+## Step 2: Use a StatefulSet to create Cassandra Ring
+
+StatefulSets (previously PetSets) are a feature that was upgraded to a Beta component in
+Kubernetes 1.5. Deploying stateful distributed applications, like Cassandra, within a clustered
+environment can be challenging. We implemented StatefulSet to greatly simplify this
+process. Multiple StatefulSet features are used within this example, but is out of
+scope of this documentation. [Please refer to the Stateful Set documentation.](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
+
+The StatefulSet manifest that is included below, creates a Cassandra ring that consists
+of three pods.
+
+This example includes using a GCE Storage Class, please update appropriately depending
+on the cloud you are working with.
+
+
+
+```yaml
+apiVersion: "apps/v1beta1"
+kind: StatefulSet
+metadata:
+ name: cassandra
+spec:
+ serviceName: cassandra
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ containers:
+ - name: cassandra
+ image: gcr.io/google-samples/cassandra:v12
+ imagePullPolicy: Always
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ resources:
+ limits:
+ cpu: "500m"
+ memory: 1Gi
+ requests:
+ cpu: "500m"
+ memory: 1Gi
+ securityContext:
+ capabilities:
+ add:
+ - IPC_LOCK
+ lifecycle:
+ preStop:
+ exec:
+ command: ["/bin/sh", "-c", "PID=$(pidof java) && kill $PID && while ps -p $PID > /dev/null; do sleep 1; done"]
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEEDS
+ value: "cassandra-0.cassandra.default.svc.cluster.local"
+ - name: CASSANDRA_CLUSTER_NAME
+ value: "K8Demo"
+ - name: CASSANDRA_DC
+ value: "DC1-K8Demo"
+ - name: CASSANDRA_RACK
+ value: "Rack1-K8Demo"
+ - name: CASSANDRA_AUTO_BOOTSTRAP
+ value: "false"
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ readinessProbe:
+ exec:
+ command:
+ - /bin/bash
+ - -c
+ - /ready-probe.sh
+ initialDelaySeconds: 15
+ timeoutSeconds: 5
+ # These volume mounts are persistent. They are like inline claims,
+ # but not exactly because the names need to match exactly one of
+ # the stateful pod volumes.
+ volumeMounts:
+ - name: cassandra-data
+ mountPath: /cassandra_data
+ # These are converted to volume claims by the controller
+ # and mounted at the paths mentioned above.
+ # do not use these in production until ssd GCEPersistentDisk or other ssd pd
+ volumeClaimTemplates:
+ - metadata:
+ name: cassandra-data
+ annotations:
+ volume.beta.kubernetes.io/storage-class: fast
+ spec:
+ accessModes: [ "ReadWriteOnce" ]
+ resources:
+ requests:
+ storage: 1Gi
+---
+kind: StorageClass
+apiVersion: storage.k8s.io/v1beta1
+metadata:
+ name: fast
+provisioner: kubernetes.io/gce-pd
+parameters:
+ type: pd-ssd
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-statefulset.yaml)
+
+
+Create the Cassandra StatefulSet as follows:
+
+```console
+$ kubectl create -f cassandra/cassandra-statefulset.yaml
+```
+
+## Step 3: Validate and Modify The Cassandra StatefulSet
+
+Deploying this StatefulSet shows off two of the new features that StatefulSets provides.
+
+1. The pod names are known
+2. The pods deploy in incremental order
+
+First validate that the StatefulSet has deployed, by running `kubectl` command below.
+
+```console
+$ kubectl get statefulset cassandra
+```
+
+The command should respond like:
+
+```console
+NAME DESIRED CURRENT AGE
+cassandra 3 3 13s
+```
+
+Next watch the Cassandra pods deploy, one after another. The StatefulSet resource
+deploys pods in a number fashion: 1, 2, 3, etc. If you execute the following
+command before the pods deploy you are able to see the ordered creation.
+
+```console
+$ kubectl get pods -l="app=cassandra"
+NAME READY STATUS RESTARTS AGE
+cassandra-0 1/1 Running 0 1m
+cassandra-1 0/1 ContainerCreating 0 8s
+```
+
+The above example shows two of the three pods in the Cassandra StatefulSet deployed.
+Once all of the pods are deployed the same command will respond with the full
+StatefulSet.
+
+```console
+$ kubectl get pods -l="app=cassandra"
+NAME READY STATUS RESTARTS AGE
+cassandra-0 1/1 Running 0 10m
+cassandra-1 1/1 Running 0 9m
+cassandra-2 1/1 Running 0 8m
+```
+
+Running the Cassandra utility `nodetool` will display the status of the ring.
+
+```console
+$ kubectl exec cassandra-0 -- nodetool status
+Datacenter: DC1-K8Demo
+======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.4.2.4 65.26 KiB 32 63.7% a9d27f81-6783-461d-8583-87de2589133e Rack1-K8Demo
+UN 10.4.0.4 102.04 KiB 32 66.7% 5559a58c-8b03-47ad-bc32-c621708dc2e4 Rack1-K8Demo
+UN 10.4.1.4 83.06 KiB 32 69.6% 9dce943c-581d-4c0e-9543-f519969cc805 Rack1-K8Demo
+```
+
+You can also run `cqlsh` to describe the keyspaces in the cluster.
+
+```console
+$ kubectl exec cassandra-0 -- cqlsh -e 'desc keyspaces'
+
+system_traces system_schema system_auth system system_distributed
+```
+
+In order to increase or decrease the size of the Cassandra StatefulSet, you must use
+`kubectl edit`. You can find more information about the edit command in the [documentation](/docs/user-guide/kubectl/kubectl_edit).
+
+Use the following command to edit the StatefulSet.
+
+```console
+$ kubectl edit statefulset cassandra
+```
+
+This will create an editor in your terminal. The line you are looking to change is
+`replicas`. The example does on contain the entire contents of the terminal window, and
+the last line of the example below is the replicas line that you want to change.
+
+```console
+# Please edit the object below. Lines beginning with a '#' will be ignored,
+# and an empty file will abort the edit. If an error occurs while saving this file will be
+# reopened with the relevant failures.
+#
+apiVersion: apps/v1beta1
+kind: StatefulSet
+metadata:
+ creationTimestamp: 2016-08-13T18:40:58Z
+ generation: 1
+ labels:
+ app: cassandra
+ name: cassandra
+ namespace: default
+ resourceVersion: "323"
+ selfLink: /apis/apps/v1beta1/namespaces/default/statefulsets/cassandra
+ uid: 7a219483-6185-11e6-a910-42010a8a0fc0
+spec:
+ replicas: 3
+```
+
+Modify the manifest to the following, and save the manifest.
+
+```console
+spec:
+ replicas: 4
+```
+
+The StatefulSet will now contain four pods.
+
+```console
+$ kubectl get statefulset cassandra
+```
+
+The command should respond like:
+
+```console
+NAME DESIRED CURRENT AGE
+cassandra 4 4 36m
+```
+
+For the Kubernetes 1.5 release, the beta StatefulSet resource does not have `kubectl scale`
+functionality, like a Deployment, ReplicaSet, Replication Controller, or Job.
+
+## Step 4: Delete Cassandra StatefulSet
+
+Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. This is done to ensure safety first, your data is more valuable than an auto purge of all related StatefulSet resources. Deleting the Persistent Volume Claims may result in a deletion of the associated volumes, depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
+
+Use the following commands to delete the StatefulSet.
+
+```console
+$ grace=$(kubectl get po cassandra-0 --template '{{.spec.terminationGracePeriodSeconds}}') \
+ && kubectl delete statefulset -l app=cassandra \
+ && echo "Sleeping $grace" \
+ && sleep $grace \
+ && kubectl delete pvc -l app=cassandra
+```
+
+## Step 5: Use a Replication Controller to create Cassandra node pods
+
+A Kubernetes
+_[Replication Controller](/docs/user-guide/replication-controller)_
+is responsible for replicating sets of identical pods. Like a
+Service, it has a selector query which identifies the members of its set.
+Unlike a Service, it also has a desired number of replicas, and it will create
+or delete Pods to ensure that the number of Pods matches up with its
+desired state.
+
+The Replication Controller, in conjunction with the Service we just defined,
+will let us easily build a replicated, scalable Cassandra cluster.
+
+Let's create a replication controller with two initial replicas.
+
+
+
+```yaml
+apiVersion: v1
+kind: ReplicationController
+metadata:
+ name: cassandra
+ # The labels will be applied automatically
+ # from the labels in the pod template, if not set
+ # labels:
+ # app: cassandra
+spec:
+ replicas: 2
+ # The selector will be applied automatically
+ # from the labels in the pod template, if not set.
+ # selector:
+ # app: cassandra
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ containers:
+ - command:
+ - /run.sh
+ resources:
+ limits:
+ cpu: 0.5
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEED_PROVIDER
+ value: "io.k8s.cassandra.KubernetesSeedProvider"
+ - name: POD_NAMESPACE
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.namespace
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ image: gcr.io/google-samples/cassandra:v12
+ name: cassandra
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ volumeMounts:
+ - mountPath: /cassandra_data
+ name: data
+ volumes:
+ - name: data
+ emptyDir: {}
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-controller.yaml)
+
+
+There are a few things to note in this description.
+
+The `selector` attribute contains the controller's selector query. It can be
+explicitly specified, or applied automatically from the labels in the pod
+template if not set, as is done here.
+
+The pod template's label, `app:cassandra`, matches the Service selector
+from Step 1. This is how pods created by this replication controller are picked up
+by the Service."
+
+The `replicas` attribute specifies the desired number of replicas, in this
+case 2 initially. We'll scale up to more shortly.
+
+Create the Replication Controller:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-controller.yaml
+
+```
+
+You can list the new controller:
+
+```console
+
+$ kubectl get rc -o wide
+NAME DESIRED CURRENT AGE CONTAINER(S) IMAGE(S) SELECTOR
+cassandra 2 2 11s cassandra gcr.io/google-samples/cassandra:v12 app=cassandra
+
+```
+
+Now if you list the pods in your cluster, and filter to the label
+`app=cassandra`, you should see two Cassandra pods. (The `wide` argument lets
+you see which Kubernetes nodes the pods were scheduled onto.)
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-21qyy 1/1 Running 0 1m kubernetes-minion-b286
+cassandra-q6sz7 1/1 Running 0 1m kubernetes-minion-9ye5
+
+```
+
+Because these pods have the label `app=cassandra`, they map to the service we
+defined in Step 1.
+
+You can check that the Pods are visible to the Service using the following service endpoints query:
+
+```console
+
+$ kubectl get endpoints cassandra -o yaml
+apiVersion: v1
+kind: Endpoints
+metadata:
+ creationTimestamp: 2015-06-21T22:34:12Z
+ labels:
+ app: cassandra
+ name: cassandra
+ namespace: default
+ resourceVersion: "944373"
+ selfLink: /api/v1/namespaces/default/endpoints/cassandra
+ uid: a3d6c25f-1865-11e5-a34e-42010af01bcc
+subsets:
+- addresses:
+ - ip: 10.244.3.15
+ targetRef:
+ kind: Pod
+ name: cassandra
+ namespace: default
+ resourceVersion: "944372"
+ uid: 9ef9895d-1865-11e5-a34e-42010af01bcc
+ ports:
+ - port: 9042
+ protocol: TCP
+
+```
+
+To show that the `SeedProvider` logic is working as intended, you can use the
+`nodetool` command to examine the status of the Cassandra cluster. To do this,
+use the `kubectl exec` command, which lets you run `nodetool` in one of your
+Cassandra pods. Again, substitute `cassandra-xxxxx` with the actual name of one
+of your pods.
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1
+UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1
+
+```
+
+## Step 6: Scale up the Cassandra cluster
+
+Now let's scale our Cassandra cluster to 4 pods. We do this by telling the
+Replication Controller that we now want 4 replicas.
+
+```sh
+
+$ kubectl scale rc cassandra --replicas=4
+
+```
+
+You can see the new pods listed:
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-21qyy 1/1 Running 0 6m kubernetes-minion-b286
+cassandra-81m2l 1/1 Running 0 47s kubernetes-minion-b286
+cassandra-8qoyp 1/1 Running 0 47s kubernetes-minion-9ye5
+cassandra-q6sz7 1/1 Running 0 6m kubernetes-minion-9ye5
+
+```
+
+In a few moments, you can examine the Cassandra cluster status again, and see
+that the new pods have been detected by the custom `SeedProvider`:
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.6 51.67 KB 256 48.9% d07b23a5-56a1-4b0b-952d-68ab95869163 rack1
+UN 10.244.1.5 84.71 KB 256 50.7% e060df1f-faa2-470c-923d-ca049b0f3f38 rack1
+UN 10.244.1.6 84.71 KB 256 47.0% 83ca1580-4f3c-4ec5-9b38-75036b7a297f rack1
+UN 10.244.0.5 68.2 KB 256 53.4% 72ca27e2-c72c-402a-9313-1e4b61c2f839 rack1
+
+```
+
+## Step 7: Delete the Replication Controller
+
+Before you start Step 5, __delete the replication controller__ you created above:
+
+```sh
+
+$ kubectl delete rc cassandra
+
+```
+
+## Step 8: Use a DaemonSet instead of a Replication Controller
+
+In Kubernetes, a [_Daemon Set_](/docs/admin/daemons) can distribute pods
+onto Kubernetes nodes, one-to-one. Like a _ReplicationController_, it has a
+selector query which identifies the members of its set. Unlike a
+_ReplicationController_, it has a node selector to limit which nodes are
+scheduled with the templated pods, and replicates not based on a set target
+number of pods, but rather assigns a single pod to each targeted node.
+
+An example use case: when deploying to the cloud, the expectation is that
+instances are ephemeral and might die at any time. Cassandra is built to
+replicate data across the cluster to facilitate data redundancy, so that in the
+case that an instance dies, the data stored on the instance does not, and the
+cluster can react by re-replicating the data to other running nodes.
+
+`DaemonSet` is designed to place a single pod on each node in the Kubernetes
+cluster. That will give us data redundancy. Let's create a
+DaemonSet to start our storage cluster:
+
+
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: DaemonSet
+metadata:
+ labels:
+ name: cassandra
+ name: cassandra
+spec:
+ template:
+ metadata:
+ labels:
+ app: cassandra
+ spec:
+ # Filter to specific nodes:
+ # nodeSelector:
+ # app: cassandra
+ containers:
+ - command:
+ - /run.sh
+ env:
+ - name: MAX_HEAP_SIZE
+ value: 512M
+ - name: HEAP_NEWSIZE
+ value: 100M
+ - name: CASSANDRA_SEED_PROVIDER
+ value: "io.k8s.cassandra.KubernetesSeedProvider"
+ - name: POD_NAMESPACE
+ valueFrom:
+ fieldRef:
+ fieldPath: metadata.namespace
+ - name: POD_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.podIP
+ image: gcr.io/google-samples/cassandra:v12
+ name: cassandra
+ ports:
+ - containerPort: 7000
+ name: intra-node
+ - containerPort: 7001
+ name: tls-intra-node
+ - containerPort: 7199
+ name: jmx
+ - containerPort: 9042
+ name: cql
+ # If you need it it is going away in C* 4.0
+ #- containerPort: 9160
+ # name: thrift
+ resources:
+ requests:
+ cpu: 0.5
+ volumeMounts:
+ - mountPath: /cassandra_data
+ name: data
+ volumes:
+ - name: data
+ emptyDir: {}
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/cassandra-daemonset.yaml)
+
+
+Most of this DaemonSet definition is identical to the ReplicationController
+definition above; it simply gives the daemon set a recipe to use when it creates
+new Cassandra pods, and targets all Cassandra nodes in the cluster.
+
+Differentiating aspects are the `nodeSelector` attribute, which allows the
+DaemonSet to target a specific subset of nodes (you can label nodes just like
+other resources), and the lack of a `replicas` attribute due to the 1-to-1 node-
+pod relationship.
+
+Create this DaemonSet:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-daemonset.yaml
+
+```
+
+You may need to disable config file validation, like so:
+
+```console
+
+$ kubectl create -f cassandra/cassandra-daemonset.yaml --validate=false
+
+```
+
+You can see the DaemonSet running:
+
+```console
+
+$ kubectl get daemonset
+NAME DESIRED CURRENT NODE-SELECTOR
+cassandra 3 3
+
+```
+
+Now, if you list the pods in your cluster, and filter to the label
+`app=cassandra`, you should see one (and only one) new cassandra pod for each
+node in your network.
+
+```console
+
+$ kubectl get pods -l="app=cassandra" -o wide
+NAME READY STATUS RESTARTS AGE NODE
+cassandra-ico4r 1/1 Running 0 4s kubernetes-minion-rpo1
+cassandra-kitfh 1/1 Running 0 1s kubernetes-minion-9ye5
+cassandra-tzw89 1/1 Running 0 2s kubernetes-minion-b286
+
+```
+
+To prove that this all worked as intended, you can again use the `nodetool`
+command to examine the status of the cluster. To do this, use the `kubectl
+exec` command to run `nodetool` in one of your newly-launched cassandra pods.
+
+```console
+
+$ kubectl exec -ti cassandra-xxxxx -- nodetool status
+Datacenter: datacenter1
+=======================
+Status=Up/Down
+|/ State=Normal/Leaving/Joining/Moving
+-- Address Load Tokens Owns (effective) Host ID Rack
+UN 10.244.0.5 74.09 KB 256 100.0% 86feda0f-f070-4a5b-bda1-2eeb0ad08b77 rack1
+UN 10.244.4.2 32.45 KB 256 100.0% 0b1be71a-6ffb-4895-ac3e-b9791299c141 rack1
+UN 10.244.3.3 51.28 KB 256 100.0% dafe3154-1d67-42e1-ac1d-78e7e80dce2b rack1
+
+```
+
+**Note**: This example had you delete the cassandra Replication Controller before
+you created the DaemonSet. This is because – to keep this example simple – the
+RC and the DaemonSet are using the same `app=cassandra` label (so that their pods map to the
+service we created, and so that the SeedProvider can identify them).
+
+If we didn't delete the RC first, the two resources would conflict with
+respect to how many pods they wanted to have running. If we wanted, we could support running
+both together by using additional labels and selectors.
+
+## Step 9: Resource Cleanup
+
+When you are ready to take down your resources, do the following:
+
+```console
+
+$ kubectl delete service -l app=cassandra
+$ kubectl delete daemonset cassandra
+
+```
+
+### Custom Seed Provider
+
+A custom [`SeedProvider`](https://svn.apache.org/repos/asf/cassandra/trunk/src/java/org/apache/cassandra/locator/SeedProvider.java)
+is included for running Cassandra on top of Kubernetes. Only when you deploy Cassandra
+via a replication control or a daemonset, you will need to use the custom seed provider.
+In Cassandra, a `SeedProvider` bootstraps the gossip protocol that Cassandra uses to find other
+Cassandra nodes. Seed addresses are hosts deemed as contact points. Cassandra
+instances use the seed list to find each other and learn the topology of the
+ring. The [`KubernetesSeedProvider`](java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)
+discovers Cassandra seeds IP addresses via the Kubernetes API, those Cassandra
+instances are defined within the Cassandra Service.
+
+Refer to the custom seed provider [README](https://github.com/kubernetes/examples/blob/master/cassandra/java/README.md) for further
+`KubernetesSeedProvider` configurations. For this example you should not need
+to customize the Seed Provider configurations.
+
+See the [image](image/) directory of this example for specifics on
+how the container docker image was built and what it contains.
+
+You may also note that we are setting some Cassandra parameters (`MAX_HEAP_SIZE`
+and `HEAP_NEWSIZE`), and adding information about the
+[namespace](/docs/user-guide/namespaces).
+We also tell Kubernetes that the container exposes
+both the `CQL` and `Thrift` API ports. Finally, we tell the cluster
+manager that we need 0.1 cpu (0.1 core).
+
+
+
+[]()
+
diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
new file mode 100644
index 0000000000..0bff22c426
--- /dev/null
+++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -0,0 +1,369 @@
+---
+title: "Example: WordPress and MySQL with Persistent Volumes"
+assignees:
+- ahmetb
+- jeffmendoza
+---
+
+This example describes how to run a persistent installation of
+[WordPress](https://wordpress.org/) and
+[MySQL](https://www.mysql.com/) on Kubernetes. We'll use the
+[mysql](https://registry.hub.docker.com/_/mysql/) and
+[wordpress](https://registry.hub.docker.com/_/wordpress/) official
+[Docker](https://www.docker.com/) images for this installation. (The
+WordPress image includes an Apache server).
+
+Demonstrated Kubernetes Concepts:
+
+* [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) to
+ define persistent disks (disk lifecycle not tied to the Pods).
+* [Services](https://kubernetes.io/docs/concepts/services-networking/service/) to enable Pods to
+ locate one another.
+* [External Load Balancers](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer)
+ to expose Services externally.
+* [Deployments](http://kubernetes.io/docs/user-guide/deployments/) to ensure Pods
+ stay up and running.
+* [Secrets](http://kubernetes.io/docs/user-guide/secrets/) to store sensitive
+ passwords.
+
+## Quickstart
+
+Put your desired MySQL password in a file called `password.txt` with
+no trailing newline. The first `tr` command will remove the newline if
+your editor added one.
+
+**Note:** if your cluster enforces **_selinux_** and you will be using [Host Path](#host-path) for storage, then please follow this [extra step](#selinux).
+
+```shell
+tr --delete '\n' .strippedpassword.txt && mv .strippedpassword.txt password.txt
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/local-volumes.yaml
+kubectl create secret generic mysql-pass --from-file=password.txt
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/mysql-deployment.yaml
+kubectl create -f https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/wordpress-deployment.yaml
+```
+
+## Table of Contents
+
+
+
+- [Persistent Installation of MySQL and WordPress on Kubernetes](#persistent-installation-of-mysql-and-wordpress-on-kubernetes)
+ - [Quickstart](#quickstart)
+ - [Table of Contents](#table-of-contents)
+ - [Cluster Requirements](#cluster-requirements)
+ - [Decide where you will store your data](#decide-where-you-will-store-your-data)
+ - [Host Path](#host-path)
+ - [SELinux](#selinux)
+ - [GCE Persistent Disk](#gce-persistent-disk)
+ - [Create the MySQL Password Secret](#create-the-mysql-password-secret)
+ - [Deploy MySQL](#deploy-mysql)
+ - [Deploy WordPress](#deploy-wordpress)
+ - [Visit your new WordPress blog](#visit-your-new-wordpress-blog)
+ - [Take down and restart your blog](#take-down-and-restart-your-blog)
+ - [Next Steps](#next-steps)
+
+
+
+## Cluster Requirements
+
+Kubernetes runs in a variety of environments and is inherently
+modular. Not all clusters are the same. These are the requirements for
+this example.
+
+* Kubernetes version 1.2 is required due to using newer features, such
+ at PV Claims and Deployments. Run `kubectl version` to see your
+ cluster version.
+* [Cluster DNS](https://github.com/kubernetes/dns) will be used for service discovery.
+* An [external load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer)
+ will be used to access WordPress.
+* [Persistent Volume Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+ are used. You must create Persistent Volumes in your cluster to be
+ claimed. This example demonstrates how to create two types of
+ volumes, but any volume is sufficient.
+
+Consult a
+[Getting Started Guide](http://kubernetes.io/docs/getting-started-guides/)
+to set up a cluster and the
+[kubectl](http://kubernetes.io/docs/user-guide/prereqs/) command-line client.
+
+## Decide where you will store your data
+
+MySQL and WordPress will each use a
+[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+to store their data. We will use a Persistent Volume Claim to claim an
+available persistent volume. This example covers HostPath and
+GCEPersistentDisk volumes. Choose one of the two, or see
+[Types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes)
+for more options.
+
+### Host Path
+
+Host paths are volumes mapped to directories on the host. **These
+should be used for testing or single-node clusters only**. The data
+will not be moved between nodes if the pod is recreated on a new
+node. If the pod is deleted and recreated on a new node, data will be
+lost.
+
+##### SELinux
+
+On systems supporting selinux it is preferred to leave it enabled/enforcing.
+However, docker containers mount the host path with the "_svirt_sandbox_file_t_"
+label type, which is incompatible with the default label type for /tmp ("_tmp_t_"),
+resulting in a permissions error when the mysql container attempts to `chown`
+_/var/lib/mysql_.
+Therefore, on selinx systems using host path, you should pre-create the host path
+directory (/tmp/data/) and change it's selinux label type to "_svirt_sandbox_file_t_",
+as follows:
+
+```shell
+## on every node:
+mkdir -p /tmp/data
+chmod a+rwt /tmp/data # match /tmp permissions
+chcon -Rt svirt_sandbox_file_t /tmp/data
+```
+
+Continuing with host path, create the persistent volume objects in Kubernetes using
+[local-volumes.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/local-volumes.yaml):
+
+```shell
+export KUBE_REPO=https://raw.githubusercontent.com/kubernetes/examples/master
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/local-volumes.yaml
+```
+
+
+### GCE Persistent Disk
+
+This storage option is applicable if you are running on
+[Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/).
+
+Create two persistent disks. You will need to create the disks in the
+same [GCE zone](https://cloud.google.com/compute/docs/zones) as the
+Kubernetes cluster. The default setup script will create the cluster
+in the `us-central1-b` zone, as seen in the
+[config-default.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/config-default.sh) file. Replace
+`` below with the appropriate zone. The names `wordpress-1` and
+`wordpress-2` must match the `pdName` fields we have specified in
+[gce-volumes.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/gce-volumes.yaml).
+
+```shell
+gcloud compute disks create --size=20GB --zone= wordpress-1
+gcloud compute disks create --size=20GB --zone= wordpress-2
+```
+
+Create the persistent volume objects in Kubernetes for those disks:
+
+```shell
+export KUBE_REPO=https://raw.githubusercontent.com/kubernetes/examples/master
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/gce-volumes.yaml
+```
+
+## Create the MySQL Password Secret
+
+Use a [Secret](http://kubernetes.io/docs/user-guide/secrets/) object
+to store the MySQL password. First create a file (in the same directory
+as the wordpress sample files) called
+`password.txt` and save your password in it. Make sure to not have a
+trailing newline at the end of the password. The first `tr` command
+will remove the newline if your editor added one. Then, create the
+Secret object.
+
+```shell
+tr --delete '\n' .strippedpassword.txt && mv .strippedpassword.txt password.txt
+kubectl create secret generic mysql-pass --from-file=password.txt
+```
+
+This secret is referenced by the MySQL and WordPress pod configuration
+so that those pods will have access to it. The MySQL pod will set the
+database password, and the WordPress pod will use the password to
+access the database.
+
+## Deploy MySQL
+
+Now that the persistent disks and secrets are defined, the Kubernetes
+pods can be launched. Start MySQL using
+[mysql-deployment.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/mysql-deployment.yaml).
+
+```shell
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/mysql-deployment.yaml
+```
+
+Take a look at [mysql-deployment.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/mysql-deployment.yaml), and
+note that we've defined a volume mount for `/var/lib/mysql`, and then
+created a Persistent Volume Claim that looks for a 20G volume. This
+claim is satisfied by any volume that meets the requirements, in our
+case one of the volumes we created above.
+
+Also look at the `env` section and see that we specified the password
+by referencing the secret `mysql-pass` that we created above. Secrets
+can have multiple key:value pairs. Ours has only one key
+`password.txt` which was the name of the file we used to create the
+secret. The [MySQL image](https://hub.docker.com/_/mysql/) sets the
+database password using the `MYSQL_ROOT_PASSWORD` environment
+variable.
+
+It may take a short period before the new pod reaches the `Running`
+state. List all pods to see the status of this new pod.
+
+```shell
+kubectl get pods
+```
+
+```
+NAME READY STATUS RESTARTS AGE
+wordpress-mysql-cqcf4-9q8lo 1/1 Running 0 1m
+```
+
+Kubernetes logs the stderr and stdout for each pod. Take a look at the
+logs for a pod by using `kubectl log`. Copy the pod name from the
+`get pods` command, and then:
+
+```shell
+kubectl logs
+```
+
+```
+...
+2016-02-19 16:58:05 1 [Note] InnoDB: 128 rollback segment(s) are active.
+2016-02-19 16:58:05 1 [Note] InnoDB: Waiting for purge to start
+2016-02-19 16:58:05 1 [Note] InnoDB: 5.6.29 started; log sequence number 1626007
+2016-02-19 16:58:05 1 [Note] Server hostname (bind-address): '*'; port: 3306
+2016-02-19 16:58:05 1 [Note] IPv6 is available.
+2016-02-19 16:58:05 1 [Note] - '::' resolves to '::';
+2016-02-19 16:58:05 1 [Note] Server socket created on IP: '::'.
+2016-02-19 16:58:05 1 [Warning] 'proxies_priv' entry '@ root@wordpress-mysql-cqcf4-9q8lo' ignored in --skip-name-resolve mode.
+2016-02-19 16:58:05 1 [Note] Event Scheduler: Loaded 0 events
+2016-02-19 16:58:05 1 [Note] mysqld: ready for connections.
+Version: '5.6.29' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)
+```
+
+Also in [mysql-deployment.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/mysql-deployment.yaml) we created a
+service to allow other pods to reach this mysql instance. The name is
+`wordpress-mysql` which resolves to the pod IP.
+
+Up to this point one Deployment, one Pod, one PVC, one Service, one Endpoint,
+two PVs, and one Secret have been created, shown below:
+
+```shell
+kubectl get deployment,pod,svc,endpoints,pvc -l app=wordpress -o wide && \
+ kubectl get secret mysql-pass && \
+ kubectl get pv
+```
+
+```shell
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+deploy/wordpress-mysql 1 1 1 1 3m
+NAME READY STATUS RESTARTS AGE IP NODE
+po/wordpress-mysql-3040864217-40soc 1/1 Running 0 3m 172.17.0.2 127.0.0.1
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
+svc/wordpress-mysql None 3306/TCP 3m app=wordpress,tier=mysql
+NAME ENDPOINTS AGE
+ep/wordpress-mysql 172.17.0.2:3306 3m
+NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
+pvc/mysql-pv-claim Bound local-pv-2 20Gi RWO 3m
+NAME TYPE DATA AGE
+mysql-pass Opaque 1 3m
+NAME CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
+local-pv-1 20Gi RWO Available 3m
+local-pv-2 20Gi RWO Bound default/mysql-pv-claim 3m
+```
+
+## Deploy WordPress
+
+Next deploy WordPress using
+[wordpress-deployment.yaml](https://github.com/kubernetes/examples/blob/master/mysql-wordpress-pd/wordpress-deployment.yaml):
+
+```shell
+kubectl create -f $KUBE_REPO/mysql-wordpress-pd/wordpress-deployment.yaml
+```
+
+Here we are using many of the same features, such as a volume claim
+for persistent storage and a secret for the password.
+
+The [WordPress image](https://hub.docker.com/_/wordpress/) accepts the
+database hostname through the environment variable
+`WORDPRESS_DB_HOST`. We set the env value to the name of the MySQL
+service we created: `wordpress-mysql`.
+
+The WordPress service has the setting `type: LoadBalancer`. This will
+set up the wordpress service behind an external IP.
+
+Find the external IP for your WordPress service. **It may take a minute
+to have an external IP assigned to the service, depending on your
+cluster environment.**
+
+```shell
+kubectl get services wordpress
+```
+
+```
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+wordpress 10.0.0.5 1.2.3.4 80/TCP 19h
+```
+
+## Visit your new WordPress blog
+
+Now, we can visit the running WordPress app. Use the external IP of
+the service that you obtained above.
+
+```
+http://
+```
+
+You should see the familiar WordPress init page.
+
+
+
+> Warning: Do not leave your WordPress installation on this page. If
+> it is found by another user, they can set up a website on your
+> instance and use it to serve potentially malicious content. You
+> should either continue with the installation past the point at which
+> you create your username and password, delete your instance, or set
+> up a firewall to restrict access.
+
+## Take down and restart your blog
+
+Set up your WordPress blog and play around with it a bit. Then, take
+down its pods and bring them back up again. Because you used
+persistent disks, your blog state will be preserved.
+
+All of the resources are labeled with `app=wordpress`, so you can
+easily bring them down using a label selector:
+
+```shell
+kubectl delete deployment,service -l app=wordpress
+kubectl delete secret mysql-pass
+```
+
+Later, re-creating the resources with the original commands will pick
+up the original disks with all your data intact. Because we did not
+delete the PV Claims, no other pods in the cluster could claim them
+after we deleted our pods. Keeping the PV Claims also ensured
+recreating the Pods did not cause the PD to switch Pods.
+
+If you are ready to release your persistent volumes and the data on them, run:
+
+```shell
+kubectl delete pvc -l app=wordpress
+```
+
+And then delete the volume objects themselves:
+
+```shell
+kubectl delete pv local-pv-1 local-pv-2
+```
+
+or
+
+```shell
+kubectl delete pv wordpress-pv-1 wordpress-pv-2
+```
+
+## Next Steps
+
+* [Introspection and Debugging](http://kubernetes.io/docs/user-guide/introspection-and-debugging/)
+* [Jobs](http://kubernetes.io/docs/user-guide/jobs/) may be useful to run SQL queries.
+* [Exec](http://kubernetes.io/docs/user-guide/getting-into-containers/)
+* [Port Forwarding](http://kubernetes.io/docs/user-guide/connecting-to-applications-port-forward/)
+
+
+[]()
+
diff --git a/docs/tutorials/stateless-application/guestbook.md b/docs/tutorials/stateless-application/guestbook.md
new file mode 100644
index 0000000000..720638c5a5
--- /dev/null
+++ b/docs/tutorials/stateless-application/guestbook.md
@@ -0,0 +1,707 @@
+---
+title: "Example: PHP Guestbook application with Redis"
+assignees:
+- ahmetb
+- jeffmendoza
+---
+
+
+This example shows how to build a simple, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/).
+
+**Table of Contents**
+
+
+ - [Guestbook Example](#guestbook-example)
+ - [Prerequisites](#prerequisites)
+ - [Quick Start](#quick-start)
+ - [Step One: Start up the redis master](#step-one-start-up-the-redis-master)
+ - [Define a Deployment](#define-a-deployment)
+ - [Define a Service](#define-a-service)
+ - [Create a Service](#create-a-service)
+ - [Finding a Service](#finding-a-service)
+ - [Environment variables](#environment-variables)
+ - [DNS service](#dns-service)
+ - [Create a Deployment](#create-a-deployment)
+ - [Optional Interlude](#optional-interlude)
+ - [Step Two: Start up the redis slave](#step-two-start-up-the-redis-slave)
+ - [Step Three: Start up the guestbook frontend](#step-three-start-up-the-guestbook-frontend)
+ - [Using 'type: LoadBalancer' for the frontend service (cloud-provider-specific)](#using-type-loadbalancer-for-the-frontend-service-cloud-provider-specific)
+ - [Step Four: Cleanup](#step-four-cleanup)
+ - [Troubleshooting](#troubleshooting)
+ - [Appendix: Accessing the guestbook site externally](#appendix-accessing-the-guestbook-site-externally)
+ - [Google Compute Engine External Load Balancer Specifics](#google-compute-engine-external-load-balancer-specifics)
+
+
+
+The example consists of:
+
+- A web frontend
+- A [redis](http://redis.io/) master (for storage), and a replicated set of redis 'slaves'.
+
+The web frontend interacts with the redis master via javascript redis API calls.
+
+**Note**: If you are running this example on a [Google Container Engine](https://cloud.google.com/container-engine/) installation, see [this Google Container Engine guestbook walkthrough](https://cloud.google.com/container-engine/docs/tutorials/guestbook) instead. The basic concepts are the same, but the walkthrough is tailored to a Container Engine setup.
+
+### Prerequisites
+
+This example requires a running Kubernetes cluster. First, check that kubectl is properly configured by getting the cluster state:
+
+```console
+$ kubectl cluster-info
+```
+
+If you see a url response, you are ready to go. If not, read the [Getting Started guides](http://kubernetes.io/docs/getting-started-guides/) for how to get started, and follow the [prerequisites](http://kubernetes.io/docs/user-guide/prereqs/) to install and configure `kubectl`. As noted above, if you have a Google Container Engine cluster set up, read [this example](https://cloud.google.com/container-engine/docs/tutorials/guestbook) instead.
+
+All the files referenced in this example can be downloaded [from GitHub](https://github.com/kubernetes/examples/tree/master/guestbook).
+
+### Quick Start
+
+This section shows the simplest way to get the example work. If you want to know the details, you should skip this and read [the rest of the example](#step-one-start-up-the-redis-master).
+
+Start the guestbook with one command:
+
+```console
+$ kubectl create -f guestbook/all-in-one/guestbook-all-in-one.yaml
+service "redis-master" created
+deployment "redis-master" created
+service "redis-slave" created
+deployment "redis-slave" created
+service "frontend" created
+deployment "frontend" created
+```
+
+Alternatively, you can start the guestbook by running:
+
+```console
+$ kubectl create -f guestbook/
+```
+
+Then, list all your Services:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.0.117 80/TCP 20s
+redis-master 10.0.0.170 6379/TCP 20s
+redis-slave 10.0.0.201 6379/TCP 20s
+```
+
+Now you can access the guestbook on each node with frontend Service's `:`, e.g. `10.0.0.117:80` in this guide. `` is a cluster-internal IP. If you want to access the guestbook from outside of the cluster, add `type: NodePort` to the frontend Service `spec` field. Then you can access the guestbook with `:NodePort` from outside of the cluster. On cloud providers which support external load balancers, adding `type: LoadBalancer` to the frontend Service `spec` field will provision a load balancer for your Service. There are several ways for you to access the guestbook. You may learn from [Accessing services running on the cluster](https://kubernetes.io/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
+
+Clean up the guestbook:
+
+```console
+$ kubectl delete -f guestbook/all-in-one/guestbook-all-in-one.yaml
+```
+
+or
+
+```console
+$ kubectl delete -f guestbook/
+```
+
+
+### Step One: Start up the redis master
+
+Before continuing to the gory details, we also recommend you to read Kubernetes [concepts and user guide](http://kubernetes.io/docs/user-guide/).
+**Note**: The redis master in this example is *not* highly available. Making it highly available would be an interesting, but intricate exercise — redis doesn't actually support multi-master Deployments at this point in time, so high availability would be a somewhat tricky thing to implement, and might involve periodic serialization to disk, and so on.
+
+#### Define a Deployment
+
+To start the redis master, use the file [redis-master-deployment.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/redis-master-deployment.yaml), which describes a single [pod](http://kubernetes.io/docs/user-guide/pods/) running a redis key-value server in a container.
+
+Although we have a single instance of our redis master, we are using a [Deployment](http://kubernetes.io/docs/user-guide/deployments/) to enforce that exactly one pod keeps running. E.g., if the node were to go down, the Deployment will ensure that the redis master gets restarted on a healthy node. (In our simplified example, this could result in data loss.)
+
+The file [redis-master-deployment.yaml](redis-master-deployment.yaml) defines the redis master Deployment:
+
+
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: redis-master
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: redis
+ # role: master
+ # tier: backend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 1
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # role: master
+ # tier: backend
+ template:
+ metadata:
+ labels:
+ app: redis
+ role: master
+ tier: backend
+ spec:
+ containers:
+ - name: master
+ image: gcr.io/google_containers/redis:e2e
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ ports:
+ - containerPort: 6379
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml)
+
+
+#### Define a Service
+
+A Kubernetes [Service](http://kubernetes.io/docs/user-guide/services/) is a named load balancer that proxies traffic to one or more containers. This is done using the [labels](http://kubernetes.io/docs/user-guide/labels/) metadata that we defined in the `redis-master` pod above. As mentioned, we have only one redis master, but we nevertheless want to create a Service for it. Why? Because it gives us a deterministic way to route to the single master using an elastic IP.
+
+Services find the pods to load balance based on the pods' labels.
+The selector field of the Service description determines which pods will receive the traffic sent to the Service, and the `port` and `targetPort` information defines what port the Service proxy will run at.
+
+The file [redis-master-service.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/redis-master-deployment.yaml) defines the redis master Service:
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: redis-master
+ labels:
+ app: redis
+ role: master
+ tier: backend
+spec:
+ ports:
+ # the port that this service should serve on
+ - port: 6379
+ targetPort: 6379
+ selector:
+ app: redis
+ role: master
+ tier: backend
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-service.yaml)
+
+
+#### Create a Service
+
+According to the [config best practices](http://kubernetes.io/docs/user-guide/config-best-practices/), create a Service before corresponding Deployments so that the scheduler can spread the pods comprising the Service. So we first create the Service by running:
+
+```console
+$ kubectl create -f guestbook/redis-master-service.yaml
+service "redis-master" created
+```
+
+Then check the list of services, which should include the redis-master:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+redis-master 10.0.76.248 6379/TCP 1s
+```
+
+This will cause all pods to see the redis master apparently running on `:`. A Service can map an incoming port to any `targetPort` in the backend pod. Once created, the Service proxy on each node is configured to set up a proxy on the specified port (in this case port `6379`).
+
+`targetPort` will default to `port` if it is omitted in the configuration. `targetPort` is the port the container accepts traffic on, and `port` is the abstracted Service port, which can be any port other pods use to access the Service. For simplicity's sake, we omit it in the following configurations.
+
+The traffic flow from slaves to masters can be described in two steps:
+
+ - A *redis slave* will connect to `port` on the *redis master Service*
+ - Traffic will be forwarded from the Service `port` (on the Service node) to the `targetPort` on the pod that the Service listens to.
+
+For more details, please see [Connecting applications](http://kubernetes.io/docs/user-guide/connecting-applications/).
+
+#### Finding a Service
+
+Kubernetes supports two primary modes of finding a Service — environment variables and DNS.
+
+
+##### Environment variables
+
+The services in a Kubernetes cluster are discoverable inside other containers via [environment variables](https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables).
+
+##### DNS service
+
+An alternative is to use the [cluster's DNS service](https://kubernetes.io/docs/concepts/services-networking/service/#dns), if it has been enabled for the cluster. This lets all pods do name resolution of services automatically, based on the Service name.
+
+This example has been configured to use the DNS service by default.
+
+If your cluster does not have the DNS service enabled, then you can use environment variables by setting the
+`GET_HOSTS_FROM` env value in both
+[redis-slave-deployment.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/redis-slave-deployment.yaml) and [frontend-deployment.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/frontend-deployment.yaml)
+from `dns` to `env` before you start up the app.
+(However, this is unlikely to be necessary. You can check for the DNS service in the list of the cluster's services by
+running `kubectl --namespace=kube-system get rc -l k8s-app=kube-dns`.)
+Note that switching to env causes creation-order dependencies, since Services need to be created before their clients that require env vars.
+
+#### Create a Deployment
+
+Second, create the redis master pod in your Kubernetes cluster by running:
+
+```console
+$ kubectl create -f guestbook/redis-master-deployment.yaml
+deployment "redis-master" created
+```
+
+You can see the Deployment for your cluster by running:
+
+```console
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+redis-master 1 1 1 1 27s
+```
+
+Then, you can list the pods in the cluster, to verify that the master is running:
+
+```console
+$ kubectl get pods
+```
+
+You'll see all pods in the cluster, including the redis master pod, and the status of each pod.
+The name of the redis master will look similar to that in the following list:
+
+```console
+NAME READY STATUS RESTARTS AGE
+redis-master-2353460263-1ecey 1/1 Running 0 1m
+...
+```
+
+(Note that an initial `docker pull` to grab a container image may take a few minutes, depending on network conditions. A pod will be reported as `Pending` while its image is being downloaded.)
+
+`kubectl get pods` will show only the pods in the default [namespace](http://kubernetes.io/docs/user-guide/namespaces/). To see pods in all namespaces, run:
+
+```
+kubectl get pods --all-namespaces
+```
+
+For more details, please see [Configuring containers](http://kubernetes.io/docs/user-guide/configuring-containers/) and [Deploying applications](http://kubernetes.io/docs/user-guide/deploying-applications/).
+
+#### Optional Interlude
+
+You can get information about a pod, including the machine that it is running on, via `kubectl describe pods/`. E.g., for the redis master, you should see something like the following (your pod name will be different):
+
+```console
+$ kubectl describe pods redis-master-2353460263-1ecey
+Name: redis-master-2353460263-1ecey
+Node: kubernetes-node-m0k7/10.240.0.5
+...
+Labels: app=redis,pod-template-hash=2353460263,role=master,tier=backend
+Status: Running
+IP: 10.244.2.3
+Controllers: ReplicaSet/redis-master-2353460263
+Containers:
+ master:
+ Container ID: docker://76cf8115485966131587958ea3cbe363e2e1dcce129e2e624883f393ce256f6c
+ Image: gcr.io/google_containers/redis:e2e
+ Image ID: docker://e5f6c5a2b5646828f51e8e0d30a2987df7e8183ab2c3ed0ca19eaa03cc5db08c
+ Port: 6379/TCP
+...
+```
+
+The `Node` is the name and IP of the machine, e.g. `kubernetes-node-m0k7` in the example above. You can find more details about this node with `kubectl describe nodes kubernetes-node-m0k7`.
+
+If you want to view the container logs for a given pod, you can run:
+
+```console
+$ kubectl logs
+```
+
+These logs will usually give you enough information to troubleshoot.
+
+However, if you should want to SSH to the listed host machine, you can inspect various logs there directly as well. For example, with Google Compute Engine, using `gcloud`, you can SSH like this:
+
+```console
+me@workstation$ gcloud compute ssh
+```
+
+Then, you can look at the Docker containers on the remote machine. You should see something like this (the specifics of the IDs will be different):
+
+```console
+me@kubernetes-node-krxw:~$ sudo docker ps
+CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
+...
+0ffef9649265 redis:latest "/entrypoint.sh redi" About a minute ago Up About a minute k8s_master.869d22f3_redis-master-dz33o_default_1449a58a-5ead-11e5-a104-688f84ef8ef6_d74cb2b5
+```
+
+If you want to see the logs for a given container, you can run:
+
+```console
+$ docker logs
+```
+
+### Step Two: Start up the redis slave
+
+Now that the redis master is running, we can start up its 'read slaves'.
+
+We'll define these as replicated pods as well, though this time — unlike for the redis master — we'll define the number of replicas to be 2.
+In Kubernetes, a Deployment is responsible for managing multiple instances of a replicated pod. The Deployment will automatically launch new pods if the number of replicas falls below the specified number.
+(This particular replicated pod is a great one to test this with -- you can try killing the Docker processes for your pods directly, then watch them come back online on a new node shortly thereafter.)
+
+Just like the master, we want to have a Service to proxy connections to the redis slaves. In this case, in addition to discovery, the slave Service will provide transparent load balancing to web app clients.
+
+This time we put the Service and Deployment into one [file](http://kubernetes.io/docs/user-guide/managing-deployments/#organizing-resource-configurations). Grouping related objects together in a single file is often better than having separate files.
+The specification for the slaves is in [all-in-one/redis-slave.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/redis-slave.yaml):
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: redis-slave
+ labels:
+ app: redis
+ role: slave
+ tier: backend
+spec:
+ ports:
+ # the port that this service should serve on
+ - port: 6379
+ selector:
+ app: redis
+ role: slave
+ tier: backend
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: redis-slave
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: redis
+ # role: slave
+ # tier: backend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 2
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # role: slave
+ # tier: backend
+ template:
+ metadata:
+ labels:
+ app: redis
+ role: slave
+ tier: backend
+ spec:
+ containers:
+ - name: slave
+ image: gcr.io/google_samples/gb-redisslave:v1
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ env:
+ - name: GET_HOSTS_FROM
+ value: dns
+ # If your cluster config does not include a dns service, then to
+ # instead access an environment variable to find the master
+ # service's host, comment out the 'value: dns' line above, and
+ # uncomment the line below.
+ # value: env
+ ports:
+ - containerPort: 6379
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/redis-slave.yaml)
+
+
+This time the selector for the Service is `app=redis,role=slave,tier=backend`, because that identifies the pods running redis slaves. It is generally helpful to set labels on your Service itself as we've done here to make it easy to locate them with the `kubectl get services -l "app=redis,role=slave,tier=backend"` command. For more information on the usage of labels, see [using-labels-effectively](http://kubernetes.io/docs/user-guide/managing-deployments/#using-labels-effectively).
+
+Now that you have created the specification, create the Service in your cluster by running:
+
+```console
+$ kubectl create -f guestbook/all-in-one/redis-slave.yaml
+service "redis-slave" created
+deployment "redis-slave" created
+
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+redis-master 10.0.76.248 6379/TCP 20m
+redis-slave 10.0.112.188 6379/TCP 16s
+
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+redis-master 1 1 1 1 22m
+redis-slave 2 2 2 2 2m
+```
+
+Once the Deployment is up, you can list the pods in the cluster, to verify that the master and slaves are running. You should see a list that includes something like the following:
+
+```console
+$ kubectl get pods
+NAME READY STATUS RESTARTS AGE
+redis-master-2353460263-1ecey 1/1 Running 0 35m
+redis-slave-1691881626-dlf5f 1/1 Running 0 15m
+redis-slave-1691881626-sfn8t 1/1 Running 0 15m
+```
+
+You should see a single redis master pod and two redis slave pods. As mentioned above, you can get more information about any pod with: `kubectl describe pods/`. And also can view the resources on [kube-ui](http://kubernetes.io/docs/user-guide/ui/).
+
+### Step Three: Start up the guestbook frontend
+
+A frontend pod is a simple PHP server that is configured to talk to either the slave or master services, depending on whether the client request is a read or a write. It exposes a simple AJAX interface, and serves an Angular-based UX.
+Again we'll create a set of replicated frontend pods instantiated by a Deployment — this time, with three replicas.
+
+As with the other pods, we now want to create a Service to group the frontend pods.
+The Deployment and Service are described in the file [all-in-one/frontend.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/frontend.yaml):
+
+
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: frontend
+ labels:
+ app: guestbook
+ tier: frontend
+spec:
+ # if your cluster supports it, uncomment the following to automatically create
+ # an external load-balanced IP for the frontend service.
+ # type: LoadBalancer
+ ports:
+ # the port that this service should serve on
+ - port: 80
+ selector:
+ app: guestbook
+ tier: frontend
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+ name: frontend
+ # these labels can be applied automatically
+ # from the labels in the pod template if not set
+ # labels:
+ # app: guestbook
+ # tier: frontend
+spec:
+ # this replicas value is default
+ # modify it according to your case
+ replicas: 3
+ # selector can be applied automatically
+ # from the labels in the pod template if not set
+ # selector:
+ # matchLabels:
+ # app: guestbook
+ # tier: frontend
+ template:
+ metadata:
+ labels:
+ app: guestbook
+ tier: frontend
+ spec:
+ containers:
+ - name: php-redis
+ image: gcr.io/google-samples/gb-frontend:v4
+ resources:
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ env:
+ - name: GET_HOSTS_FROM
+ value: dns
+ # If your cluster config does not include a dns service, then to
+ # instead access environment variables to find service host
+ # info, comment out the 'value: dns' line above, and uncomment the
+ # line below.
+ # value: env
+ ports:
+ - containerPort: 80
+```
+
+[Download example](https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/frontend.yaml)
+
+
+#### Using 'type: LoadBalancer' for the frontend service (cloud-provider-specific)
+
+For supported cloud providers, such as Google Compute Engine or Google Container Engine, you can specify to use an external load balancer
+in the service `spec`, to expose the service onto an external load balancer IP.
+To do this, uncomment the `type: LoadBalancer` line in the [all-in-one/frontend.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/frontend.yaml) file before you start the service.
+
+[See the appendix below](#appendix-accessing-the-guestbook-site-externally) on accessing the guestbook site externally for more details.
+
+Create the service and Deployment like this:
+
+```console
+$ kubectl create -f guestbook/all-in-one/frontend.yaml
+service "frontend" created
+deployment "frontend" created
+```
+
+Then, list all your services again:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.63.63 80/TCP 1m
+redis-master 10.0.76.248 6379/TCP 39m
+redis-slave 10.0.112.188 6379/TCP 19m
+```
+
+Also list all your Deployments:
+
+```console
+$ kubectl get deployments
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+frontend 3 3 3 3 2m
+redis-master 1 1 1 1 39m
+redis-slave 2 2 2 2 20m
+```
+
+Once it's up, i.e. when desired replicas match current replicas (again, it may take up to thirty seconds to create the pods), you can list the pods with specified labels in the cluster, to verify that the master, slaves and frontends are all running. You should see a list containing pods with label 'tier' like the following:
+
+```console
+$ kubectl get pods -L tier
+NAME READY STATUS RESTARTS AGE TIER
+frontend-1211764471-4e1j2 1/1 Running 0 4m frontend
+frontend-1211764471-gkbkv 1/1 Running 0 4m frontend
+frontend-1211764471-rk1cf 1/1 Running 0 4m frontend
+redis-master-2353460263-1ecey 1/1 Running 0 42m backend
+redis-slave-1691881626-dlf5f 1/1 Running 0 22m backend
+redis-slave-1691881626-sfn8t 1/1 Running 0 22m backend
+```
+
+You should see a single redis master pod, two redis slaves, and three frontend pods.
+
+The code for the PHP server that the frontends are running is in `examples/guestbook/php-redis/guestbook.php`. It looks like this:
+
+```php
+ 'tcp',
+ 'host' => $host,
+ 'port' => 6379,
+ ]);
+
+ $client->set($_GET['key'], $_GET['value']);
+ print('{"message": "Updated"}');
+ } else {
+ $host = 'redis-slave';
+ if (getenv('GET_HOSTS_FROM') == 'env') {
+ $host = getenv('REDIS_SLAVE_SERVICE_HOST');
+ }
+ $client = new Predis\Client([
+ 'scheme' => 'tcp',
+ 'host' => $host,
+ 'port' => 6379,
+ ]);
+
+ $value = $client->get($_GET['key']);
+ print('{"data": "' . $value . '"}');
+ }
+} else {
+ phpinfo();
+} ?>
+```
+
+Note the use of the `redis-master` and `redis-slave` host names -- we're finding those Services via the Kubernetes cluster's DNS service, as discussed above. All the frontend replicas will write to the load-balancing redis-slaves service, which can be highly replicated as well.
+
+### Step Four: Cleanup
+
+If you are in a live Kubernetes cluster, you can just kill the pods by deleting the Deployments and Services. Using labels to select the resources to delete is an easy way to do this in one command.
+
+```console
+$ kubectl delete deployments,services -l "app in (redis, guestbook)"
+```
+
+To completely tear down a Kubernetes cluster, if you ran this from source, you can use:
+
+```console
+$ /cluster/kube-down.sh
+```
+
+### Troubleshooting
+
+If you are having trouble bringing up your guestbook app, double check that your external IP is properly defined for your frontend Service, and that the firewall for your cluster nodes is open to port 80.
+
+Then, see the [troubleshooting documentation](http://kubernetes.io/docs/troubleshooting/) for a further list of common issues and how you can diagnose them.
+
+
+
+### Appendix: Accessing the guestbook site externally
+
+You'll want to set up your guestbook Service so that it can be accessed from outside of the internal Kubernetes network. Above, we introduced one way to do that, by setting `type: LoadBalancer` to Service `spec`.
+
+More generally, Kubernetes supports two ways of exposing a Service onto an external IP address: `NodePort`s and `LoadBalancer`s , as described [here](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types).
+
+If the `LoadBalancer` specification is used, it can take a short period for an external IP to show up in `kubectl get services` output, but you should then see it listed as well, e.g. like this:
+
+```console
+$ kubectl get services
+NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+frontend 10.0.63.63 23.236.59.54 80/TCP 1m
+redis-master 10.0.76.248 6379/TCP 39m
+redis-slave 10.0.112.188 6379/TCP 19m
+```
+
+Once you've exposed the service to an external IP, visit the IP to see your guestbook in action, i.e. `http://:`.
+
+You should see a web page that looks something like this (without the messages). Try adding some entries to it!
+
+
+
+If you are more advanced in the ops arena, you can also manually get the service IP from looking at the output of `kubectl get pods,services`, and modify your firewall using standard tools and services (firewalld, iptables, selinux) which you are already familiar with.
+
+#### Google Compute Engine External Load Balancer Specifics
+
+In Google Compute Engine, Kubernetes automatically creates forwarding rules for services with `LoadBalancer`.
+
+You can list the forwarding rules like this (the forwarding rule also indicates the external IP):
+
+```console
+$ gcloud compute forwarding-rules list
+NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
+frontend us-central1 130.211.188.51 TCP us-central1/targetPools/frontend
+```
+
+In Google Compute Engine, you also may need to open the firewall for port 80 using the [console][cloud-console] or the `gcloud` tool. The following command will allow traffic from any source to instances tagged `kubernetes-node` (replace with your tags as appropriate):
+
+```console
+$ gcloud compute firewall-rules create --allow=tcp:80 --target-tags=kubernetes-node kubernetes-node-80
+```
+
+For GCE Kubernetes startup details, see the [Getting started on Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/)
+
+For Google Compute Engine details about limiting traffic to specific sources, see the [Google Compute Engine firewall documentation][gce-firewall-docs].
+
+[cloud-console]: https://console.developer.google.com
+[gce-firewall-docs]: https://cloud.google.com/compute/docs/networking#firewalls
+
+
+[]()
+
diff --git a/images/docs/meanstack/MEANstack_architecture.svg b/images/docs/meanstack/MEANstack_architecture.svg
deleted file mode 100644
index 25171b2c47..0000000000
--- a/images/docs/meanstack/MEANstack_architecture.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
diff --git a/images/docs/meanstack/image_0.png b/images/docs/meanstack/image_0.png
deleted file mode 100644
index 92f7fa45ce..0000000000
Binary files a/images/docs/meanstack/image_0.png and /dev/null differ
diff --git a/images/docs/meanstack/image_1.png b/images/docs/meanstack/image_1.png
deleted file mode 100644
index 974ec0b0ae..0000000000
Binary files a/images/docs/meanstack/image_1.png and /dev/null differ
diff --git a/images/docs/meanstack/image_2.png b/images/docs/meanstack/image_2.png
deleted file mode 100644
index f856a537af..0000000000
Binary files a/images/docs/meanstack/image_2.png and /dev/null differ
diff --git a/images/docs/meanstack/image_3.png b/images/docs/meanstack/image_3.png
deleted file mode 100644
index 32d874d406..0000000000
Binary files a/images/docs/meanstack/image_3.png and /dev/null differ
diff --git a/images/docs/meanstack/image_4.png b/images/docs/meanstack/image_4.png
deleted file mode 100644
index a8f2d4e346..0000000000
Binary files a/images/docs/meanstack/image_4.png and /dev/null differ
diff --git a/images/docs/meanstack/image_5.png b/images/docs/meanstack/image_5.png
deleted file mode 100644
index 54e284b0f3..0000000000
Binary files a/images/docs/meanstack/image_5.png and /dev/null differ
diff --git a/images/docs/meanstack/image_6.png b/images/docs/meanstack/image_6.png
deleted file mode 100644
index 1af2b517d7..0000000000
Binary files a/images/docs/meanstack/image_6.png and /dev/null differ
diff --git a/images/docs/meanstack/image_7.png b/images/docs/meanstack/image_7.png
deleted file mode 100644
index 7774803073..0000000000
Binary files a/images/docs/meanstack/image_7.png and /dev/null differ
diff --git a/js/redirects.js b/js/redirects.js
index a6cb150c5f..b434b0aa49 100644
--- a/js/redirects.js
+++ b/js/redirects.js
@@ -80,7 +80,16 @@ $( document ).ready(function() {
{
"from": "/docs/concepts/services-networking/networkpolicies/",
"to": "/docs/concepts/services-networking/network-policies/"
- }];
+ },
+ {
+ "from": "/docs/getting-started-guides/meanstack/",
+ "to": "https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-app-engine-and-mongolab-4bbd2040ea75"
+ },
+ {
+ "from": "/docs/samples/",
+ "to": "/docs/tutorials/"
+ }
+ ];
forwardingRules.forEach(function(rule) {
if (forwardingURL.indexOf(rule.from) > -1) {
diff --git a/js/script.js b/js/script.js
index d6ff1dacf8..9b9dde3958 100755
--- a/js/script.js
+++ b/js/script.js
@@ -25,7 +25,7 @@ function copyCode(elem){
}
target.value = document.getElementById(elem).innerText;
// select the content
- target.setSelectionRange(0, target.value.length);
+ target.select();
// copy the selection
var succeed;
@@ -520,4 +520,4 @@ $(function() {
if (!$('#home').length > 0 ) {
$('#hero').addClass('no-sub');
}
-});
\ No newline at end of file
+});
+
+If you are more advanced in the ops arena, you can also manually get the service IP from looking at the output of `kubectl get pods,services`, and modify your firewall using standard tools and services (firewalld, iptables, selinux) which you are already familiar with.
+
+#### Google Compute Engine External Load Balancer Specifics
+
+In Google Compute Engine, Kubernetes automatically creates forwarding rules for services with `LoadBalancer`.
+
+You can list the forwarding rules like this (the forwarding rule also indicates the external IP):
+
+```console
+$ gcloud compute forwarding-rules list
+NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
+frontend us-central1 130.211.188.51 TCP us-central1/targetPools/frontend
+```
+
+In Google Compute Engine, you also may need to open the firewall for port 80 using the [console][cloud-console] or the `gcloud` tool. The following command will allow traffic from any source to instances tagged `kubernetes-node` (replace with your tags as appropriate):
+
+```console
+$ gcloud compute firewall-rules create --allow=tcp:80 --target-tags=kubernetes-node kubernetes-node-80
+```
+
+For GCE Kubernetes startup details, see the [Getting started on Google Compute Engine](http://kubernetes.io/docs/getting-started-guides/gce/)
+
+For Google Compute Engine details about limiting traffic to specific sources, see the [Google Compute Engine firewall documentation][gce-firewall-docs].
+
+[cloud-console]: https://console.developer.google.com
+[gce-firewall-docs]: https://cloud.google.com/compute/docs/networking#firewalls
+
+
+[]()
+
diff --git a/images/docs/meanstack/MEANstack_architecture.svg b/images/docs/meanstack/MEANstack_architecture.svg
deleted file mode 100644
index 25171b2c47..0000000000
--- a/images/docs/meanstack/MEANstack_architecture.svg
+++ /dev/null
@@ -1,4 +0,0 @@
-
-
-
-
diff --git a/images/docs/meanstack/image_0.png b/images/docs/meanstack/image_0.png
deleted file mode 100644
index 92f7fa45ce..0000000000
Binary files a/images/docs/meanstack/image_0.png and /dev/null differ
diff --git a/images/docs/meanstack/image_1.png b/images/docs/meanstack/image_1.png
deleted file mode 100644
index 974ec0b0ae..0000000000
Binary files a/images/docs/meanstack/image_1.png and /dev/null differ
diff --git a/images/docs/meanstack/image_2.png b/images/docs/meanstack/image_2.png
deleted file mode 100644
index f856a537af..0000000000
Binary files a/images/docs/meanstack/image_2.png and /dev/null differ
diff --git a/images/docs/meanstack/image_3.png b/images/docs/meanstack/image_3.png
deleted file mode 100644
index 32d874d406..0000000000
Binary files a/images/docs/meanstack/image_3.png and /dev/null differ
diff --git a/images/docs/meanstack/image_4.png b/images/docs/meanstack/image_4.png
deleted file mode 100644
index a8f2d4e346..0000000000
Binary files a/images/docs/meanstack/image_4.png and /dev/null differ
diff --git a/images/docs/meanstack/image_5.png b/images/docs/meanstack/image_5.png
deleted file mode 100644
index 54e284b0f3..0000000000
Binary files a/images/docs/meanstack/image_5.png and /dev/null differ
diff --git a/images/docs/meanstack/image_6.png b/images/docs/meanstack/image_6.png
deleted file mode 100644
index 1af2b517d7..0000000000
Binary files a/images/docs/meanstack/image_6.png and /dev/null differ
diff --git a/images/docs/meanstack/image_7.png b/images/docs/meanstack/image_7.png
deleted file mode 100644
index 7774803073..0000000000
Binary files a/images/docs/meanstack/image_7.png and /dev/null differ
diff --git a/js/redirects.js b/js/redirects.js
index a6cb150c5f..b434b0aa49 100644
--- a/js/redirects.js
+++ b/js/redirects.js
@@ -80,7 +80,16 @@ $( document ).ready(function() {
{
"from": "/docs/concepts/services-networking/networkpolicies/",
"to": "/docs/concepts/services-networking/network-policies/"
- }];
+ },
+ {
+ "from": "/docs/getting-started-guides/meanstack/",
+ "to": "https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-app-engine-and-mongolab-4bbd2040ea75"
+ },
+ {
+ "from": "/docs/samples/",
+ "to": "/docs/tutorials/"
+ }
+ ];
forwardingRules.forEach(function(rule) {
if (forwardingURL.indexOf(rule.from) > -1) {
diff --git a/js/script.js b/js/script.js
index d6ff1dacf8..9b9dde3958 100755
--- a/js/script.js
+++ b/js/script.js
@@ -25,7 +25,7 @@ function copyCode(elem){
}
target.value = document.getElementById(elem).innerText;
// select the content
- target.setSelectionRange(0, target.value.length);
+ target.select();
// copy the selection
var succeed;
@@ -520,4 +520,4 @@ $(function() {
if (!$('#home').length > 0 ) {
$('#hero').addClass('no-sub');
}
-});
\ No newline at end of file
+});
