So far the world has had very little use of our pingpong-service, but now we are going to change that!

As in the world of computers in general there is no single way of solving a problem and the same applies to Internet exposure. We're going to focus mainly on the standard GCP ways of doing so which is using a LoadBalancer-object for simple HTTP (not recommended!) access and an Ingress-object for more proper HTTP(S) access.

If you're still in the load-balanced-deployment folder then run the command below to get rid of any existing resources.

kustomize build . | kubectl delete -f -

Change to the following folder:

cd ../internet-exposure/loadbalancer

The set of files that your find here look exactly the same as in the previous example except for one thing, the service has changed from a ClusterIP to a LoadBalancer. This will allocate a public IP-adress for your service.

apiVersion: v1
kind: Service
metadata:
  name: pingpong-service
spec:
  type: LoadBalancer
  ports:
    - port: 8080

Let's deploy what in this folder using kustomize build-command, you should know how by now! After running your kustomize command run the following command to observe the LoadBalancer:

kubectl get services -n pingpong

If you are faster than Googles IP allocation you will see something like the following:

NAME               TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)          AGE
pingpong-service   LoadBalancer   172.21.6.14   <pending>        8080:30132/TCP   2s

Use the Unix watch command here or you will go crazy! After some time your LoadBalancer will be allocated an IP-address. Something like this (although your IP will most likely be different):

NAME               TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)          AGE
pingpong-service   LoadBalancer   172.21.6.14   35.246.159.241   8080:30132/TCP   89s

This is actually all, believe it or not, pingpong-service is available on the Internet. Open up your web browser, type in the following URL:

http://<your-IP>:8080/ping?name=Jon Doe

You should see something like the following (not very sexy!):

But it IS nice to be on the Internet!

Ok, the LoadBalancer was easy but it's not likely everyting that you want. You will need HTTPS support, most applications do.

So, lets get rid of the stuff that's deployed now:

kustomize build . | kubectl delete -f -

Now navigate to the other subfolder of internet-exposure:

cd ../ingress

This will deploy an Ingress-object taking traffic from the Internet and allowing it to your pingpong-service. Ingresses is the way to go for HTTPS-setups. You can add your own Ingress controller solution to a GKE-cluster, like Traefik, haproxy or Nginx, but for now we are going to use the built-in one.

List the files in the folder and you'll se that there is, among others, a new one called ingress.yaml. Inspect it and you'll see:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: pingpong-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "pingpong-static-ip"
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: tls-certificate-secret
spec:
  rules:
    - host: dev.pingpong.com
      http:
        paths:
          - path: /ping
            backend:
              serviceName: pingpong-service
              servicePort: 8080

There are a few things to notice here.

• First, it's the kubernetes.io/ingress.global-static-ip-name: "pingpong-static-ip" annotation in the metadata-section. I've chosen to make this example as realistic as possible and so in a real world case you'd want a fix, static IP for your service(s). We will learn below how to allocate such an address

• Second, there's a tls entry; tls-certificate-secret. This is a certificate allowing us to operate the service over HTTPS which you want in a real world case. In this case the certificate is just fake, of course, but the technique is the same regardless of the certificates authenticity

• Third, backing up again to the metadata-section, there is another annotation kubernetes.io/ingress.allow-http: "false" saying that this service is not AT ALL available through HTTP. Only HTTPS is possible.

• Fourth, a host name is specified for the ingress; - dev.pingpong.com. This is fake, just like the certificate, but it demonstrates how you tie your ingress to a real domain/host and, of course, in combination with a real certificate for that host. You can tie the same ingress to multiple hosts under the same spec and you can also have multiple paths pointing to different backends under the same host

• Fifth, there is a file called pingpong-ingress.crt that contains the public certificate that you can add to your tool/browser so that the self-signed fake cert becomes trusted. As an alternative you can curl with -k option (insecure) to just bypass security

... is as easy as one-two-three with GCP! Just type in the following command in your console:

gcloud compute addresses create pingpong-static-ip --global

It will take a short while for GCP to allocate the address but you can check status by using the corresponding list command, when you see your address it's done:

gcloud compute addresses list

A very important notice on IP addresses!!!

Google, like others, charges significantly for unused IP addresses and this is something you want to avoid. So make sure you delete the IP address when you are done with this example/showcase!

The rest has been prepared so just run:

kustomize build . | kubectl apply -f -

Allocating the ingress controller will take some time, don't be upset if it takes anything between 5 and 10 minutes. The easiest way to see the status of the controller is to view it in the Google Cloud web console.

This time however we won't be able to access the service using an IP-address. This is because we've mapped it with a host name in the ingress, remember; - dev.pingpong.com. Now, this domain is of course fake so you have to make your computer understand how to map dev.pingpong.com to an IP-address. This is done by manipulating your hosts file. On a Mac the hosts file is located under /etc/hosts. There is a script provided in the current folder that you can use or you can edit it manually with the proper IP address.

Copy the following to your console to run the script (will require your root password for the computer):

sh . /add-pingpong-dev-host.sh

Manually you can open you hosts file by typing (will also require root password):

sudo vi /etc/hosts

Then use insert mode to add the desired record and save it. You can inspect the result by doing a more /etc/hosts, this will print the contents and it should look similar to this:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost


34.120.219.164  dev.pingpong.com

Although, of course, you will most likely have a different IP address allocated as your static IP. Now if you use the command below you should be able to cURL the service and get the same output as before with the LoadBalancer:

While the ingress is becoming available you may receive 404 and 50* errors, don't worry, keep trying every minute.

curl -k https://dev.pingpong.com/ping?name=Jon%20Doe

You can also try to open the URL in your browser, depending on security settings, and perhaps browser, you may or may not be able to continue to the page although the certificate is not valid.

Congrats!!! You've just deployed an HTTPS secured RESTful web service in the Cloud. That's a pretty near real life experience and the steps used in this showcase pretty much adds up to how it's done in its simplest form.

In the next section you'll learn how to stay on budget by scaling your service up and down depending on the workload.