In this document, I try to demonstrate a use case of kubernetes to deploy a simple static web page. 

The network in kubernetes  usually will have a topology like the figure below. In this example, we will start from the bottom, which are pods, and will build up the network.

Step 0: have a webserver docker image ready with the contents of your web page

• There are various ways to deploy web server on the k8s. Here we assume that you have a docker image of the web server and all the contents of your pages. 
• We will use "registry.kasi.re.kr/uwife/uwife_www" that I (Jae-Joon Lee) have personally created.
• The image is based on nginx web server and the copy of the web pages I will serve.
• The Dockerfile and all its contents are available at https://data.kasi.re.kr/gitlab/leejjoon/uwife-www

Step 1: Deployment

• The "deployment" resource is often used when you want scalable number of pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: uwife-www
spec:
  replicas: 1
  selector:
    matchLabels:
      app: uwife-www
  template:
    metadata:
      labels:
        app: uwife-www
    spec:
      containers:
      - name: uwife-www
        image: registry.kasi.re.kr/uwife/uwife_www

• We see that it has created a pod with an internal ip of 10.100.95.194.
• The ip is only accessible inside the k8s cluster (including, master and worker nodes).
• To test, lets login to the master node.
• Note that to login to the master (or worker nodes), you need to set the ssh-key properly while creating the cluster. You can 

Step 2: Create a service for external connection.

• To access the pod from outside, you need to create a service resource for it.
• Here we will use "NodePort" type service. With the "NodePort" service, you will create a connection from a port in any of the worker nodes to the pod.

apiVersion: v1
kind: Service
metadata:
  name: uwife-www
spec:
  type: NodePort
  selector:
    app: uwife-www
  ports:
  - port: 80
    targetPort: 80

• Now, if you can reach any of the k8s nodes (only the worker nodes), you can reach the pod with the port number 31349

• Similarly, you can assign a virtual ip by creating a "LoadBalancer" service.
• But, for now, the loadbalancer requires floating ip assigned to it, which can limit its usage.
• Instead, you can use Ingress resources. It can create a internal vip and/or use same ip for different services.

Step 3: Create am Ingress for external connection with routing.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-internal-ingress
  annotations:
    kubernetes.io/ingress.class: "openstack"
    octavia.ingress.kubernetes.io/internal: "true"
spec:
 rules:
 - host: k8s-10.gems0.org
   http:
     paths:
     - path: /
       pathType: Prefix
       backend:
         serviceName: uwife-www
         servicePort: 80

• Note that on line 7, we specify "internal" as true. Thus it won't try to allocate external floating ip.
• We also says the if the incoming traffic haas a target Host name of "k8s-10.gems0.org", the traffic will be forwarded to the "uwife-www" service.
• We are using "octavia" ingress controller for openstack, and it only allows NodePort service as a backend.
• Once you apply that yaml file to create the ingress object, you will see a ip address will be assigned (this can take several seconds). Note that this will automatically create an loadbalancer object in the openstack.
• And your web page accessible with the allocated ip (10.0.1.156 in this case), but the Header should specify the host name of k8s-10.gems0.org.

• Similarly, you can create an ingress object with an external floating ip. However, in this case, you can access multiple services by having different rules for different services (e.g., different host name)

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-external-ingress
  annotations:
    kubernetes.io/ingress.class: "openstack"
    octavia.ingress.kubernetes.io/internal: "false"
spec:
 rules:
 - host: k8s-10.gems0.org
   http:
     paths:
     - path: /
       pathType: Prefix
       backend:
         serviceName: uwife-www
         servicePort: 80

• The only change we made (other than the name) is t set "internal" as false in line 7. Thus it will try to allocate the floating ip.
• In this case, the floating ip of "210.219.33.217" is assigned to this ingress object.
• Note that you can add multiple rules to the above yaml file and reapply to have this ingress object to forward your traffic to multiple services.

• Now, change your DNS seeting so that the host name of "k8s-10.gems0.org" to the ip of 210.219.33.217.
• We assume you have your own domain you can manipulate. If not, you may test it with nip hostname (https://nip.io/). In this case, duplicate the host rule in the yaml with the host name replaced with "210-219-33-217.nip.io"
  
• Once the DNS is set, you can access the side with the host name.

• And now you can open the page in your web browser.
• Of course, the site is only accessible from the KAS intranet because of the KASAI firewall. If you want allow public access, you need to talk to the KASI computer management team to allow inbound traffic on that ip address.

• You can setup a ssl certificate for your site and make HTTPS connection accessible, but this won't be covered here.

Step 4: Scale out your web page.

• If your web page become super popular, a single web server cannot handle your traffic.
• The virtue of kubernetes is its ease of scaling out.
• You simply change the "replicas" number (line 6) and reapply. And you will have multiple pods serving your web page.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: uwife-www
spec:
  replicas: 3
  selector:
    matchLabels:
      app: uwife-www
  template:
    metadata:
      labels:
        app: uwife-www
    spec:
      containers:
      - name: uwife-www
        image: registry.kasi.re.kr/uwife/uwife_www

• Note that the service object you created will automatically divide the traffic to each pod.
• In the example below, note the uwife-www service now have 3 endpoints pointing each pods.