Tuesday, November 17, 2020

How to automate management of TLS certificates on GKE

 If you looking for a way to manage certificates to your Kubernetes clusters here's one that I tried out.
You can set this up within a few minutes and not have to worry about expired certificates.


Create a GKE cluster:

gcloud container clusters create smartcluster --addons HttpLoadBalancing --preemptible 


Get Credentials from the cluster

gcloud container clusters get-credentials smartcluster

 

Create a deployment:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginxsvc-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: kubernetes
  replicas: 1
  template:
    metadata:
      labels:
        greeting: hello
        department: kubernetes
    spec:
      containers:
      - name: hello-again
        image: "nginx"
        env:
        - name: "PORT"
          value: "80"
EOF

 Create a Service:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: nginxsvc
spec:
  type: NodePort
  selector:
    greeting: hello
    department: kubernetes
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
EOF


 

Create the managed certificate for your  domain name:
 

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
  name: test-nginx-cert
spec:
  domains:
    - nginx.sankhe.com #enter your domain name here
EOF

 Create a loadbalancer for the ingress and attach the managed certificate.

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # If the class annotation is not specified it defaults to "gce".
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/managed-certificates: test-nginx-cert
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: nginxsvc
          servicePort: 80
EOF

 

 

status:
  certificateName: mcrt-a2730924-e05a-4e37-a969-98801086e215
  certificateStatus: Provisioning
  domainStatus:
  - domain: nginx.sankhe.com
    status: Provisioning



It takes approximately 15-20 minutes for the status to turn into Active

k get managedcertificates/nginx-cert -o yaml --watch
apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.gke.io/v1beta2","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"nginx-cert","namespace":"default"},"spec":{"domains":["nginx.sankhe.com"]}}
  creationTimestamp: "2020-11-18T00:07:22Z"
  generation: 3
  name: nginx-cert
  namespace: default
  resourceVersion: "10824"
  selfLink: /apis/networking.gke.io/v1beta2/namespaces/default/managedcertificates/nginx-cert
  uid: b4380ec7-650c-4858-b74a-d1f4f874d99b
spec:
  domains:
  - nginx.sankhe.com
status:
  certificateName: mcrt-1b17be8f-b51e-427c-9dc1-15ea72097202
  certificateStatus: Provisioning
  domainStatus:
  - domain: nginx.sankhe.com
    status: FailedNotVisible

 In cases where the status shows as FailedNotVisible. The following steps could help diagnose the problem.

 

dig nginx.sankhe.com

;; ANSWER SECTION:
nginx.sankhe.com.    2858    IN    A    34.120.42.225

kubectl get ingress my-ingress get -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
34.120.42.225

The IP of the ingress loadbalancer should match the value in the DNS records. If it doesnt match the DNS records need to be updated.



apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.gke.io/v1beta2","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"nginx-cert","namespace":"default"},"spec":{"domains":["nginx.sankhe.com"]}}
  creationTimestamp: "2020-11-18T00:07:22Z"
  generation: 4
  name: nginx-cert
  namespace: default
  resourceVersion: "27768"
  selfLink: /apis/networking.gke.io/v1beta2/namespaces/default/managedcertificates/nginx-cert
  uid: b4380ec7-650c-4858-b74a-d1f4f874d99b
spec:
  domains:
  - nginx.sankhe.com
status:
  certificateName: mcrt-1b17be8f-b51e-427c-9dc1-15ea72097202
  certificateStatus: Active
  domainStatus:
  - domain: nginx.sankhe.com
    status: Active
  expireTime: "2021-02-15T16:31:51.000-08:00"

Test using your browser or even on the command line.

curl https://nginx.sankhe.com #replace this with your domain.



Saturday, November 7, 2020

Top 5 reasons to choose Cloud Run

 


Clouds — Photo by SKi

What’s Cloud Run?

One liner version:

Cloud Run is a serverless compute platform on the Google Cloud Platform that enables you to run stateless containers invocable via HTTP requests.

Two words version:

Serverless containers


Top Five Reasons:

1. Any language, any library, any binary

Test your Docker container locally with any language along with any dependancies.

2. Container to production in seconds

Deploy your container to production with single click.

[![Run on Google Cloud](https://storage.googleapis.com/cloudrun/button.svg)](https://console.cloud.google.com/cloudshell/editor?shellonly=true&cloudshell_image=gcr.io/cloudrun/button&cloudshell_git_repo=[YOUR_HTTP_GIT_URL])

This creates a button like the following:

Runs on Google — one click deploy button
Single Click Deploy

3. Pay‐per‐use

First 2 million requests are part of the always-free Tier every month.

4. Fully Managed

No infrastructure to manage: once deployed, Cloud Run manages your services so you can sleep well.

5. Portable

Built on Knative. That means you can run it anywhere Kubernetes runs even on-prem, never worry about vendor lock-in.

How to automate management of TLS certificates on GKE

 If you looking for a way to manage certificates to your Kubernetes clusters here's one that I tried out. You can set this up within a f...