Category: Cloud (Page 7 of 9)

CKA Exam Experience (Inc study & lab guide)

May 7, 2019 / David / 3 Comments

Introduction

Over the long bank holiday weekend, I sat and passed the Certified Kubernetes Exam (CKA). This blog post goes over my experience (With respect to the NDA) together with a lab guide I’ve made which I’ve uploaded hoping it might help others.

Format

The online exams consist of a set of performance-based items (problems) to be solved on the command line. For the CKA there are 24 questions of varying difficulty. At the time of writing, the only option to sit this exam is through remote proctoring.

This link contains the most pertinent information to assimilate.

Experience

I’m a huge fan of practical exams. I’m so glad the powers at be decided to go down this route. I absolutely loathe multiple choice exams for many reasons. The remote proctoring was a new experience for me, and I wasn’t completely comfortable with it. Given the choice, I would have preferred to go to a test center. I hope The Linux Foundation adds this option in the future.

I sat the exam first time around feeling relatively confident, but knew I had some weaker areas. After a painstaking wait I received the following email:

confused oh no GIF by It's Always Sunny in Philadelphia

I brushed myself off, crammed the areas I was weaker on, took the exam again and waited….

…and waited

From my experience, as a techie, I get a much more accomplished feeling when passing practical exams, such as this / VCAP’s etc. Either way, to say I was happy would be a gross understatement.

Takeaways

A lot of people say this exam is “hard”. I get really discouraged reading up on peoples exam experiences saying exams are “hard”. I would say a more accurate adjective for this exam would be “Fair”. Know the curriculum, practice your craft, and you’ll get there.
Lean on the documentation as much as you need to. You have access to kubernetes.io/docs during the exam.
It’s a practical exam, so practice, practice, and practice some more.
You get a free retake, so don’t worry if you don’t pass first time.
kubectl run somedeployment –image=nginx –replicas=5 –dry-run -o yaml. Output existing or new objects to a yaml file if you need to make finer adjustments or create objects from scratch.

Lab Guide

My revision approach for this exam predominantly consisted of:

Reading up on the topics
Apply the knowledge to practical examples
Validate the approach

I ended up with three documents:

Revision Notes
Practice lab exercises
Practice lab exercises answers (writing this helped me commit this information to memory)

All of which can be found at https://github.com/David-VTUK/CKA-StudyGuide

Exposing the K8s dashboard via a NSX-T Load balancer

April 15, 2019 / David / 0 Comments

For the following to work, your k8s infrastructure needs to leverage some kind of CNI that’s able to provision load balancers. For this example I’m leveraging PKS which has native integration with NSX-T.

The default way to access the Kubernetes dashboard is to leverage the kubectl proxy command. However, this is somewhat limiting for a production environment. An alternative way is to expose the dashboard through a load balancer.

Modify the Dashboard service by executing : kubectl -n kube-system edit service kubernetes-dashboard and modifying the “type” field from “ClusterIP” to “LoadBalancer”

Afterwards, the service will be reconfigured to be presented by a load balancer external VIP.

At which point we can access it directly:

PKS, Harbor and the importance of container registries

February 27, 2019 / David / 0 Comments

What are container registries and why do we need them?

A lot of the time, particularly when individuals and organisations are evaluating, testing and experimenting with containers they will use public container registries such as Docker Hub. These public registries provide an easy-to-use, simple way to access images. As developers, application owners, system admins etc gain familiarity and experience additional operational considerations need to be explored, such as:

Organisation – How can we organise container images in a meaningful way? Such as by environment state (Prod/Dev/Test) and application type?
RBAC – How can we implement role-based access control to a container registry?
Vulnerability Scanning – How can we scan container images for known vulnerabilities?
Efficiency – How can we centrally manage all our container images and deploy an application from them?
Security – Some images need to kept under lock and key, rather than using an external service like Docker Hub.

Introducing VMware Harbor Registry

VMware Harbor Registry has been designed to address these considerations as enterprise-class container registry solution with integration into PKS. In this post, We’ll have a quick primer on getting up and running with Harbor in PKS and explore some of its features. To begin, we need to download PKS Harbor from the Pivotal site and import it into ops manager.

After which the tile will be added (When doing this for the first time it will have an orange bar at the bottom. Press the tile to configure).

The following need to be defined with applicable parameters to suit your environment.

Availability Zone and Networks – This is where the Harbor VM will reside, and the respective configuration will be dependent on your setup.
General – Hostname and IP address settings
Certificate – Generate a self-signed certificate, or BYOC (bring your own certificate)
Credentials – Define the local admin password
Authentication – Choose between
- Internal
- LDAP
- UAA in PKS
- UAA in PAS
Container Registry store – Choose where to store container images pushed to Harbor
- Local file system
- NFS Server
- S3 Bucket
- Google Cloud Storage
Clair Proxy Settings
Notary settings
Resource Config

VMware Harbor Registry – Organisation

Harbor employs the concept of “projects”. Projects are a way of collecting images for a specific application or service. When images are pushed to Harbor, they reside within a project:

Projects can either be private or public and can be configured during, or after, project creation:

A project is comprised of a number of components:

VMware Harbor Registry – RBAC

In Harbor, we have three role types we can assign to projects:

rbac

Image source: https://github.com/goharbor/harbor/blob/master/docs/user_guide.md#managing-projects

Guest – Read-only access, can pull images
Developer – Read/write access, can pull and push images
Admin – Read/Write access, as well as project-level activities, such as modifying parameters and permissions.

As a practical example, AD groups can be created to facilitate these roles:

And these AD groups can be mapped to respective permissions within the project

Therefore, facilitating RBAC within our Harbor environment. Pretty handy.

VMware Harbor Registry – Vulnerability Scanning

The ability to identify, evaluate and remediate vulnerabilities is a standard operation is modern software development and deployment. Thankfully Harbor addresses this with integration with Clair – an open source project that addresses the identification, categorisation and analysis of vulnerabilities within containers. As a demonstration we need to first push an image to Harbor:

After initiating a scan, Harbor can inform us of what vulnerabilities exist within this container image

We can then explore more details about these vulnerabilities, including when they were fixed:

Conclusion

Harbor provides us with an enterprise level, container registry solution. This blog post has only scratched the surface, and with constant development being invested into the project, expect more features and improvements.