Deploying and exposing the frontend

Now it's getting pretty predictable and boring (exactly how deployments should be).

Run the following command:

kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml

To verify the deployment, run this code:

ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
deployment.apps/frontend created
ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kc get pods
NAME READY STATUS RESTARTS AGE
frontend-56f7975f44-h9d78 0/1 Pending 0 2s
frontend-56f7975f44-kw428 0/1 Pending 0 3s
frontend-56f7975f44-nt55q 0/1 Pending 0 2s

You don't get any points for guessing that this Deployment specifies a replica count of 3 (OK, maybe a pat in the back; we are generous people). The Deployment has the usual suspects with minor changes as shown in the following code:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: frontend
labels:
app: guestbook
spec:
selector:
matchLabels:
app: guestbook
tier: frontend
replicas: 3
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
# Using `GET_HOSTS_FROM=dns` requires your cluster to
# provide a dns service. As of Kubernetes 1.3, DNS is a built-in
# service launched automatically. However, if the cluster you are using
# does not have a built-in DNS service, you can instead
# access an environment variable to find the master
# service's host. To do so, comment out the 'value: dns' line above, and
# uncomment the line below:
# value: env
ports:
- containerPort: 80

The replica count is set to 3, the labels are set to {app:guestbook, tier:frontend}, and the image used is gb-frontend:v4.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset