Knative architecture

Scheduling services on ECS – Containers as a Service (CaaS) and Serverless Computing for Containers

ECS services are similar to Kubernetes ReplicaSets. They ensure that a certain number of tasks are always running at a particular time. To schedule a service, we can use the ecs-cli command line.

Tip

Always use services for applications that are long-running, such as web servers. For batch jobs, always use tasks, as we don’t want to recreate the job after it ends.

To run the nginx web server as a service, we can use the following command:

$ ecs-cli compose service up –create-log-groups \

–cluster cluster-1 –launch-type FARGATE

INFO[0001] Using ECS task definition TaskDefinition=”FARGATE:1″

INFO[0002] Auto-enabling ECS Managed Tags

INFO[0013] (service FARGATE) has started 1 tasks: (task 9b48084d).   timestamp=”2023-07-03

11:24:42 +0000 UTC”

INFO[0029] Service status desiredCount=1 runningCount=1 serviceName=FARGATE

INFO[0029] (service FARGATE) has reached a steady state. timestamp=”2023-07-03 11:25:00 +0000 UTC”

INFO[0029] (service FARGATE) (deployment ecs-svc/94284856) deployment completed. timestamp=”2023-07-03 11:25:00 UTC”

INFO[0029] ECS Service has reached a stable state desiredCount=1 runningCount=1 serviceName=FARGATE

INFO[0029] Created an ECS service service=FARGATE taskDefinition=”FARGATE:1″

Looking at the logs, we can see that the service is trying to ensure that the task’s desired count matches the task’s running count. If your task is deleted, ECS will replace it with a new one.

Let’s list the tasks and see what we get by using the following command:

$ ecs-cli ps –cluster cluster-1 Name State Ports cluster-1/9b48084d/web RUNNING 18.234.123.71:80

TaskDefinition

FARGATE:1

As we can see, the service has created a new task that is running on 18.234.123.71:80. Let’s try to access this URL using the following command:

$ curl 18.234.123.71

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

…

</html>

We get the default nginx home page in the response. Now, let’s try to browse the logs of the task.

Browsing container logs using the ECS CLI

Apart from using Amazon CloudWatch, you can also use the friendly ECS CLI to do this, irrespective of where your logs are stored. This helps us see everything from a single pane of glass.

Run the following command to do so:

$ ecs-cli logs –task-id 9b48084d –cluster cluster-1 /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/ default.conf

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2023/07/03 11:24:57 [notice] 1#1: nginx/1.25.1

2023/07/03 11:24:57 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)

2023/07/03 11:24:57 [notice] 1#1: OS: Linux 5.10.184-175.731.amzn2.x86_64

2023/07/03 11:24:57 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 65535:65535

2023/07/03 11:24:57 [notice] 1#1: start worker processes

2023/07/03 11:24:57 [notice] 1#1: start worker process 29

2023/07/03 11:24:57 [notice] 1#1: start worker process 30

13.232.8.130 – – [03/Jul/2023:11:30:38 +0000] “GET / HTTP/1.1” 200 615 “-” “curl/7.81.0”

“-“

As we can see, we can browse the logs for the particular task this service is running. Now, let’s go ahead and delete the service.

2023-02-04 by Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Amazon ECS with EC2 and Fargate – Containers as a Service (CaaS) and Serverless Computing for Containers-2

ECS is a cloud-based regional service. When you spin up an ECS cluster, the instances span multiple AZs, where you can schedule your tasks and services using simple manifests. ECS manifests are very similar to docker-compose YAML manifests, where we specify which tasks to run and which tasks comprise a service.

You can run ECS within an existing VPC. We can schedule tasks in either Amazon EC2 or AWS Fargate.

Your ECS cluster can have one or more EC2 instances attached to it. You also have the option to attach an existing EC2 instance to a cluster by installing the ECS node agent within your EC2 instance. The agent sends information about your containers’ state and tasks to the ECS scheduler. It then interacts with the container runtime to schedule containers within the node. They are similar to kubelet in the Kubernetes ecosystem. If you run your containers within EC2 instances, you pay for the number of EC2 instances you allocate to the cluster.

If you plan to use Fargate, the infrastructure is wholly abstracted from you, and you must specify the amount of CPU and memory your container is set to consume. You pay for the CPU and memory your container consumes rather than the resources you allocate to the machines.

Tip

Although you only pay for the resources you consume in Fargate, it is more expensive than running your tasks on EC2, especially when running long -running services such as a web server. A rule of thumb is to run long-running online tasks within EC2 and batch tasks with Fargate. That will give you the best cost optimization.

When we schedule a task, AWS spins up the container on a managed EC2 or Fargate server by pulling the required container image from a container registry. Every task has an elastic network interface (ENI) attached to it. Multiple tasks are grouped as a service, and the service ensures that all the required tasks run at once.

Amazon ECS uses a task scheduler to schedule containers on your cluster. It places your containers in an appropriate node of your cluster based on placement logic, availability, and cost requirements. The scheduler also ensures that the desired number of tasks run on the node at a given time.

The following diagram explains the ECS cluster architecture beautifully:

Figure 7.1 – ECS architecture

Amazon provides the ECS command-line interface (CLI) for interacting with the ECS cluster. It is a simple command-line tool that you can use to administer an ECS cluster and create and manage tasks and services on the ECS cluster.

Now, let’s go ahead and install the ECS CLI.

2022-08-15 by Building the Python Flask app Cloud Certifications Exams of Cloud Knative architecture Load testing your app on Knative 0

Amazon ECS with EC2 and Fargate – Containers as a Service (CaaS) and Serverless Computing for Containers-1

Amazon ECS is a container orchestration platform that AWS offers. It is simple to use and manage, uses Docker behind the scenes, and can deploy your workloads to Amazon EC2, a virtual machine (VM)-based solution, or AWS Fargate, a serverless offering.

It is a highly scalable solution that deploys containers in seconds. It makes hosting, running, stopping, and starting your containers easy. Just as Kubernetes offers pods, ECS offers tasks that help you run your container workloads. A task can contain one or more containers grouped according to a logical relationship. You can also group one or more tasks into services . Services are similar to Kubernetes controllers, which manage tasks and can ensure that the required number of replicas of your tasks are running in the right place at the right time. ECS uses simple API calls to provide many functionalities, such as creating, updating, reading, and deleting tasks and services.

ECS also allows you to place your containers according to multiple placement strategies while keeping high availability (HA) and resource optimization in mind. You can tweak the placement algorithm according to your priority—cost, availability, or a mix of both. So, you can use ECS to run one-time batch workloads or long-running microservices, all using a simple-to-use API interface.

ECS architecture

Before we explore the ECS architecture, it is important to understand some common AWS terminologies to follow it. Let’s look at some AWS resources:

  • AWS Regions: An AWS Region is a geographical region where AWS provides its services. It is normally a city or a metropolitan region but can sometimes span multiple cities. It comprises multiple Availability Zones (AZs). Some examples of AWS Regions are us-east-1, us-west-1, ap-southeast-1, eu-central-1, and so on.
  • AWS AZs: AWS AZs are data centers within an AWS Region connected with low-latency, high-bandwidth networks. Most resources run within AZs. Examples of AZs are us-east-1a, us-east-1b, and so on.
  • AWS virtual private cloud (VPC): An AWS VPC is an isolated network resource you create within AWS. You associate a dedicated private IP address range to it from which the rest of your resources, such as EC2 instances, can derive their IP addresses. An AWS VPC spans an AWS Region.
  • Subnet: A subnet, as the name suggests, is a subnetwork within the VPC. You must subdivide the IP address ranges you provided to the VPC and associate them with subnets. Resources normally reside within subnets, and each subnet spans an AZ.
  • Containers as a Service (CaaS) and Serverless Computing for Containers
  • Route table: An AWS route table routes traffic within the VPC subnets and to the internet. Every AWS subnet is associated with a route table through subnet route table associations.
    • Internet gateways: An internet gateway allows connection to and from the internet to your AWS subnets.
  • Identity Access Management (IAM): AWS IAM helps you control access to resources by users and other AWS resources. They help you implement role-based access control (RBAC) and the principle of least privilege (PoLP).
  • Amazon EC2: EC2 allows you to spin up VMs within subnets, also known as instances.
  • AWS Auto Scaling groups (ASGs): An AWS ASG works with Amazon EC2 to provide HA and scalability to your instances. It monitors your EC2 instances and ensures that a defined number of healthy instances are always running. It also takes care of autoscaling your instances with increasing load in your machines to allow for handling more traffic. It uses theinstance profile and launch configuration to decide on the properties of new EC2 instances it spins up.
  • Amazon CloudWatch: Amazon CloudWatch is a monitoring and observability service. It allows you to collect, track, and monitor metrics, log files, and set alarms to take automated actions on specific conditions. CloudWatch helps understand application performance, health, and resource utilization.
2022-07-21 by Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative 0

Troubleshooting containers with busybox using an alias – Managing Advanced Kubernetes Resources

We use the following commands to open a busybox session:

$ kubectl run busybox-test –image=busybox -it –rm –restart=Never — <cmd>

Now, opening several busybox sessions during the day can be tiring. How about minimizing the overhead by using the following alias?

$ alias kbb=’kubectl run busybox-test –image=busybox -it –rm –restart=Never –‘

We can then open a shell session to a new busybox pod using the following command:

$ kbb sh

/ #

Now, that is much cleaner and easier. Likewise, you can also create aliases of other commands that you use frequently. Here’s an example:

$ alias kgp=’kubectl get pods’

$ alias kgn=’kubectl get nodes’

$ alias kgs=’kubectl get svc’

$ alias kdb=’kubectl describe’

$ alias kl=’kubectl logs’

$ alias ke=’kubectl exec -it’

And so on, according to your needs. You may also be used to autocompletion within bash, where your commands autocomplete when you press Tab after typing a few words. kubectl also provides autocompletion of commands, but not by default. Let’s now look at how to enable kubectl autocompletion within bash.

Using kubectl bash autocompletion

To enable kubectl bash autocompletion, use the following command:

$ echo “source <(kubectl completion bash)” >> ~/.bashrc

The command adds the kubectl completion bash command as a source to your .bashrc file. So, the next time you log in to your shell, you should be able to use kubectl autocomplete. That will save you a ton of time when typing commands.

Summary

We began this chapter by managing pods with Deployment and ReplicaSet resources and discussed some critical Kubernetes deployment strategies. We then looked into Kubernetes service discovery and models and understood why we required a separate entity to expose containers to the internal or external world. We then looked at different Service resources and where to use them. We talked about Ingress resources and how to use them to create reverse proxies for our container workloads. We then delved into Horizontal Pod autoscaling and used multiple metrics to scale our pods automatically.

We looked at state considerations and learned about static and dynamic storage provisioning using

PersistentVolume, PersistentVolumeClaim, and StorageClass resources, and talked about some best practices surrounding them. We looked at StatefulSet resources as essential resources that help you schedule and manage stateful containers. Finally, we looked at some best practices, tips, and tricks surrounding the kubectl command line and how to use them effectively.

The topics covered in this and the previous chapter are just the core of Kubernetes. Kubernetes is a vast tool with enough functionality to write an entire book, so these chapters only give you the gist of what it is all about. Please feel free to read about the resources in detail in the Kubernetes official documentation at https://kubernetes.io.

In the next chapter, we will delve into the world of the cloud and look at Container-as-a-Service (CaaS) and serverless offerings for containers.

2022-02-08 by Building the Python Flask app Deleting an ECS service Exams of Cloud Knative architecture Providing variable values 0

Dynamic provisioning – Managing Advanced Kubernetes Resources

Dynamic provisioning is when Kubernetes provides storage resources for you by interacting with the cloud provider. When we provisioned the disk manually, we interacted with the cloud APIs using the gcloud command line. What if your organization decides to move to some other cloud provider later? That would break many existing scripts, and you would have to rewrite the storage provisioning steps. Kubernetes is inherently portable and platform-independent. You can provision resources in the same way on any cloud platform.

But then, different cloud providers have different storage offerings. How would Kubernetes know what kind of storage it needs to provision? Well, Kubernetes uses StorageClass resources for that. StorageClass resources are Kubernetes resources that define the type of storage they need to provide when someone uses it.

The following diagram illustrates dynamic provisioning:

Figure 6.10 – Dynamic provisioning

Let’s see an example storage class manifest, fast-storage-class.yaml, that provisions an SSD within GCP:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd

The StorageClass resource contains a provisioner and any parameters the provisioner requires. You may have noticed that I have kept the name fast instead of gce-ssd or similar. That is because we want to keep the names as generic as possible.

Tip

Keep generic storage class names such as fast, standard, block, and shared, and avoid names specific to the cloud platform. Because storage class names are used in Persistent Volume claims, if you migrate to another cloud provider, you may end up changing a lot of manifests just to avoid confusion.

Let’s go ahead and apply the manifest using the following command:

$ kubectl apply -f fast-storage-class.yaml

As the StorageClass resource is created, let’s use it to provision an nginx StatefulSet resource dynamically.

We need to create a Service resource manifest, nginx-dynamic-service.yaml, first:

apiVersion: v1
kind: Service
metadata:
name: nginx-dynamic
labels:
app: nginx-dynamic
spec:
ports:
port: 80
name: web
clusterIP: None
selector:
app: nginx-dynamic

The manifest is very similar to the manual Service resource. Let’s go ahead and apply it using the following command:
$ kubectl apply -f nginx-dynamic-service.yaml
Now, let’s look at the StatefulSet resource manifest, nginx-dynamic-statefulset.yaml:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-dynamic
spec:
…
serviceName: “nginx-dynamic”
template:
spec:
containers:
name: nginx
image: nginx volumeMounts:
name: html
mountPath: /usr/share/nginx/html
…
volumeClaimTemplates:
metadata:
name: html
spec:
storageClassName: “fast”
accessModes: [ “ReadWriteOnce” ]
resources:
requests:
storage: 40Gi

The manifest is similar to the manual one, but this one contains the storageClassName attribute in the volumeClaimTemplates section and lacks the selector section, as we are dynamically provisioning the storage. Use the following command to apply the manifest:

$ kubectl apply -f nginx-dynamic-statefulset.yaml

As the StatefulSet resource is created, let’s go ahead and check the PersistentVolumeClaim and PersistentVolume resources using the following commands:

$ kubectl get pvc     
NAME STATUSVOLUMECAPACITYACCESS MODES  STORAGECLASS
html-nginx-dynamic-0Boundpvc-6b7840GiRWOfast
$ kubectl get pv     
NAMECAPACITYACCESS MODES  RECLAIM POLICYSTATUSCLAIM
pvc-6b7840GiRWODelete Bounddefault/html-nginx-dynamic-0

And we can see that the claim is bound to a Persistent Volume that is dynamically provisioned. Now, let’s proceed and run the following command to do similar tests with this StatefulSet resource.

Let’s create a file in the nginx-dynamic-0 pod using the following command:

$ kubectl exec -it nginx-dynamic-0 — bash

root@nginx-dynamic-0:/# cd /usr/share/nginx/html/ root@nginx-dynamic-0:/usr/share/nginx/html# echo ‘Hello, dynamic world’ > index.html root@nginx-dynamic-0:/usr/share/nginx/html# exit

Now, delete the pod and open a shell session again to check whether the file exists by using the following commands:

$kubectl delete pod nginx-dynamic-0  
$kubectl get podnginx-dynamic-0  
NAMEREADYSTATUSRESTARTSAGE
nginx-dynamic-01/1Running013s

$ kubectl exec -it nginx-dynamic-0 — bash
root@nginx-dynamic-0:/# cd /usr/share/nginx/html/
root@nginx-dynamic-0:/usr/share/nginx/html# cat index.html
Hello, dynamic world
root@nginx-dynamic-0:/usr/share/nginx/html# exit

And as we can see, the file exists in the volume, even if the pod was deleted. That is dynamic provisioning in action for you!

You will have observed that we have used the kubectl command multiple times throughout this chapter. When you perform activities throughout the day, using shortcuts and best practices wherever you can makes sense. Let’s look at some best practices while using kubectl.

2021-12-06 by Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0