CloudProfs 17: Linkerd and AWS exam best practice!

Welcome to an abridged issue 17 of CloudProfs, which went out to subscribers on November 20.

Want to read this week’s What’s Been Said and Done in Cloud This Week? Catch it here.


LINKERD: OVERVIEW, TUTORIAL AND APPROACHES

Linkerd, a service mesh for Kubernetes, was first noted in CloudProfs #4 back in August, as the technology had ‘graduated’ from the Cloud Native Computing Foundation (CNCF). In other words, it had achieved a level of maturity both in product and customer acquisition. Expedia, Microsoft, and Nordstrom are three of the larger customer examples.

Linkerd 2.11, which hit the wires at the end of September, made a big step forward in introducing policy, a feature which allows users to control which service are allowed to connect and send requests to each other. An even smaller proxy and control plane were also delivered in this iteration; Linkerd’s lightweight and zippy calling card owes much to its being written in Rust, both for performance and security.

Below is a roundup of recently-published resources around Linkerd, from beginner tutorials on how to get started, to more intermediate and advanced offerings.

A video from Viktor Farcic at DevOps Toolkit, published November 8, goes through the basics of Linkerd and how to set up proxy injection and observability. Farcic used the analogy of a hotel to describe why service meshes were necessary. Every hotel has rooms, but the occupants of those rooms are changing. Within a system, processes need to be able to communicate with each other, find each other, and work out what happens if communication gets interrupted. Organisations need to discover who is where, and be able to communicate with all parties securely.

For complex systems, there are various facets which can be required; discovery, load balancing, failure recovery, monitoring, rate limiting, access control, authentication… the list goes on. While hardly any users need all of those facets, almost everybody needs some of them; and this is where a service mesh comes in.

To set up Linkerd, as per this demonstration, you need two things: a Kubernetes cluster and an ingress controller. Unlike tools such as Istio, Linkerd does not come with ingress baked in. Rancher Desktop, for K8s and container management, was used, which comes with Traefik ingress.

Execute the following script to install:

curl -sL https://run.linkerd.io/install | sh

Use the following for pre- and  post-installation checks in the CLI respectively:

linkerd check –pre

linkerd check

Compared with Rancher Desktop, this article from Joseph Eshiett outlines Linkerd integration with Minikube, a tool which allows users to run Kubernetes on their local machines. Eshiett has similar processes to Farcic, including noting the use of linkerd check to assess whether Linkerd and Minikube have been installed correctly, installing the Linkerd control plane into a Kubernetes cluster, which was created automatically when Minikube was started.

Viz, which is based on Prometheus and Grafana, is necessary here for monitoring. This can be done using the following, with linkerd viz install generating a K8s manifest with all Viz resources, then piping (|) into kubectl apply:

linkerd viz install | kubectl apply -f –

For a more advanced DIY use case, this article from Tarasov Aleksandr makes for interesting reading regarding using Linkerd with Kubernetes Jobs. At this time, Linkerd does not work with Kubenetes Jobs or CronJobs without extra work – as Jobs are especially difficult resources to be meshed. The injected likerd-proxy continues to run after the job container completes its work.

There are two potential workarounds for this (the first referenced is to not use Linkerd for jobs):

1 Manually call Linkerd proxy shutdown hook. Aleksandr asserts this is an ugly solution, but this can be used to manually signal that the proxy should terminate instead of relying on a SIGTERM, with a ‘shutdown’ endpoint to the proxy’s admin server.

command: [“/bin/sh”]
args: [“-c”,
“<job_run_command_here>”,
“; CODE=$?; wget –post-data hello=shutdown http://localhost:4191/shutdown; exit $CODE;”]

2 Use linkerd-await. This is a command wrapper that checks Linkerd’s readiness, and is able to call shutdown hook after a command ends.

command: [“/linkerd-await”]
args: [“–shutdown”, “–“, “/coolcommand”]

There is an addendum to using linkerd-await which can be seen in the article.


EXAM RESOURCE: AWS CERTIFIED SOLUTIONS ARCHITECT – ASSOCIATE (AWS TRAINING AND CERTIFICATION)

Watch the webinar on demand here.

Exam: AWS Certified Solutions Architect – Associate <Online/Offline (130 minutes, Multiple Choice)> 

Candidates: Solutions Architects 

Trainer: Patrick Bentley, Technical Trainer – Amazon Web Services 

Domains covered: 

  • Design Resilient Architectures (30%) 
  • Design High Performing Architectures (28%) 
  • Design Secure Applications and Architectures (24%) 
  • Design Co-optimized Architectures (18%) 

Webinar focus: 

  • Question strategy  
  • Content 

Practice makes perfect – this adage is especially true when certification exams are approaching. The AWS Certified Solutions Architect – Associate webinar is the perfect tool to gain insights in preparation for the exam. This webinar helps understand topics in focus and set expectations for the exam. It outlines a general strategy that includes studying the five pillars of AWS well architected framework that serve as a foundation for terminology. Other strategies include identifying AWS features in the question as well as the answers to ease picking the correct response among the given options. 

In terms of the domains that the exam covers, the first one focuses on designing – decoupling mechanisms using AWS services, multi-tier architecture solution, high ability, and fault tolerant solutions. For this domain during the exams, students should consider that AWS managed services be preferred, assume everything will fail at some point so design accordingly and that fault tolerance and high availability are not the same thing. The second domain is geared towards choosing performance storage and databases as well as design features that enable operational excellence, applying cache to improve performance, and designing solutions for elasticity and scalability. While taking the exam, learners must consider monitoring metrics, providing alerts for anomalous conditions, automating responses where possible and remember that IAM roles are easier and safer than keys and passwords. The third domain talks about determining how to secure application tiers and data and defines the network infrastructure for a single VPC application. During the exam for this domain, learners must remember to lock down the AWS root user and that security groups only ALLOW while network ACLs ALLOW explicit DENY. The last domain looks at determining how to design cost-optimized storage as well as compute. For this domain, while answering questions learners should keep in mind to reserve if something is going to be on, determine most cost-effective EC2 pricing model and instance type for each workload, and use cost-effective systems realizing that any unused CPU storage is a wastage. 

This webinar details the subject areas that the learners might expect in the exam. In doing so, it guides them how to tackle questions in a manner that will help them pick the correct one. This webinar would prove to be helpful for anyone looking to take the AWS Certified Solutions Architect – Associate exam.  

Timestamps for reference: 

00:00 – Exam and Trainer Introduction
03:15 – Webinar Agenda
04:02 – What is covered in the course?
05:20 – Why certify?
08:38 – Question Allocation
09:55 – The Exam: Logistics, sample questions
16:45 – General Strategy
18:55 – Domain 1: Design Resilient Architectures
41:51 – Domain 2: Design High Performing Architectures
01:05:23 – Domain 3: Design Secure Applications and Architectures
01:25:23 – Domain 4: Design Co-optimized Architectures
01:38:43 – Wrapping up the course
01:39:39 – Sample question


SECRET KNOWLEDGE

100DaysOfPowerShell: A current system administrator who wants to solve problems in his job is committing to software development through learning PowerShell and C#/ .NET development. Yet to begin day 1. Also look out for Azure Architect Roadmap from the same author.

NEW! Cloud-Architect-Interview-Questions: A list of questions that can be asked during an interview for a cloud architect position (though sadly no answers!)

Diagrams: Diagram as Code for prototyping cloud system architectures. Primary language: Python (94.8%)

KinK: A helper CLI that facilitates KinD clusters as Kubernetes pods. Designed to ease clusters up for fast testing with batteries included in mind. Latest release: v0.1.1 (Sep 15). Primary language: Go (74.4%)

Porter: A Kubernetes-powered PaaS that runs in your own cloud provider. Porter brings the Heroku experience to your own AWS/GCP account, while upgrading your infrastructure to Kubernetes. Latest release: v0.11.2 (Nov 4). Primary language: Go (54.7%), TypeScript (44.2%)

Shipwright: An extensible framework for building container images on Kubernetes. Latest release: v0.6.0 (Oct 7). Primary language: Go (94.8%)

Leave a Reply

Your email address will not be published. Required fields are marked *