The newbie cloud architect diary

$ cat << EOF > petstore-svcdepl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: petstore-deployment
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: petstore
  replicas: 2
  template: 
    metadata:
      labels:
        app: petstore
    spec:
      containers:
      - name: petstore-worker
        image: openapitools/openapi-petstore
        ports:
        - containerPort: 8080
        env:
        - name: OPENAPI_BASE_PATH
          value: "/v3"
---
kind: Service
apiVersion: v1
metadata:
  name: petstore-service
spec:
  selector:
    app: petstore
  type: LoadBalancer
  ports:
    - name: petstore-port
      port: 80
      targetPort: 8080
EOF
$ kubectl -n default apply -f petstore-svcdepl.yaml
deployment.apps/petstore-deployment created
service/petstore-service created

$ cat << EOF > petstore-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: petstore-ingress
spec:
  rules:
  - host: petstore.host
    http:
      paths:
      - path: /
        backend:
          serviceName: petstore-service
          servicePort: 80
EOF
$ kubectl -n default apply -f petstore-ingress.yaml
ingress.extensions/petstore-ingress created
$ export KONG_PROXY_URL="http://$(kubectl describe svc kong-kong-proxy | grep Endpoints: | grep 8000 | awk '{print $2}')"
$ curl -H "Host: petstore.host" -H "api_key: special-key" \
    "$KONG_PROXY_URL/v3/store/inventory"
{"sold":1,"pending":2,"available":7}

$ kubectl -n default delete -f petstore-ingress.yaml
$ helm del --purge konga
$ helm del --purge kong
$ kubens default
$ kubectl delete namespace gloo

• Gloo Ingress mode scans for Ingress objects (like Kong Ingress Controller). Gloo offers no real added-value to this approach and therefore does not recommend it.
• Gloo Gateway mode discovers Service objects. The Gloo "way" to Cloud Native that can integrate with Service Mesh.

$ kubectl create namespace gloo
$ kubens gloo
$ helm repo add gloo-os-with-ui https://storage.googleapis.com/gloo-os-ui-helm
$ helm repo update
$ helm install --name gloo gloo-os-with-ui/gloo-os-with-ui \
    --set ingress.enabled=false,gateway.enabled=true,crds.create=true \
    --set gloo.gatewayProxies.gatewayProxy.readConfig=enabled \
    --version 1.4.0

• proxy: Envoy endpoint listening to all incoming trafic on TCP ports 8080/8443.
• gateway: Validates and translates Gateway, Virtual Service, and RouteTable custom resources into a Proxy custom resource.
• gloo: Validates Proxy custom resource and creates an Envoy configuration.
• discovery: Service discovery server.
• api-server: Administration API, Administration UI, gRPC proxy.

$ wget https://github.com/solo-io/gloo/releases/latest/download/glooctl-linux-amd64
$ chmod +x glooctl-linux-amd64 && mv glooctl-linux-amd64 ~/.local/bin/glooctl
$ glooctl -n gloo version
Client: {"version":"1.4.1"}
Server: {"type":"Gateway","kubernetes":{"containers":[{"Tag":"1.4.0","Name":"grpcserver-ui","Registry":"quay.io/solo-io"},{"Tag":"1.4.0","Name":"grpcserver-ee","Registry":"quay.io/solo-io"},{"Tag":"1.4.0","Name":"grpcserver-envoy","Registry":"quay.io/solo-io"},{"Tag":"1.4.1","Name":"discovery","Registry":"quay.io/solo-io"},{"Tag":"1.4.1","Name":"gateway","Registry":"quay.io/solo-io"},{"Tag":"1.4.1","Name":"gloo-envoy-wrapper","Registry":"quay.io/solo-io"},{"Tag":"1.4.1","Name":"gloo","Registry":"quay.io/solo-io"}],"namespace":"gloo"}}
$ glooctl -n gloo get upstreams | head -10
+---------------------------------+------------+----------+--------------------------------+
|            UPSTREAM             |    TYPE    |  STATUS  |            DETAILS             |
+---------------------------------+------------+----------+--------------------------------+
| default-kubernetes-443          | Kubernetes | Accepted | svc name:      kubernetes      |
|                                 |            |          | svc namespace: default         |
|                                 |            |          | port:          443             |
|                                 |            |          |                                |
| default-petstore-service-80     | Kubernetes | Accepted | svc name:                      |
|                                 |            |          | petstore-service               |
|                                 |            |          | svc namespace: default         |

Gloo Administration API

Because the API is based on gRPC, the user should access it using Gloo client only. 

Since we use Flux operator for any modification to our productive cluster and since glooctl is not able to simulate resource creation, we have to clarify wether a direct access can be approved for automation and if yes, if we need to retro-store VirtualService objects as follows. 

$ glooctl get virtualservice default --output kube-yaml

As workaround we may also invoke the API from the CI-Pipeline using a gRPC client (ex. grpcurl).

Gloo Administration UI

$ sensible-browser $(kubectl describe svc apiserver-ui \
    | grep Endpoints: | awk '{print $2}')

$ glooctl -n gloo delete virtualservice default
$ helm del --purge gloo
$ kubectl delete namespace gloo