Forem: ylcnky

Kubernetes Patters: The Sidecar

ylcnky — Sun, 16 Jan 2022 20:44:12 +0000

The basic idea on which UNIX was designed is to not have a complex monolithic tool do everything. Instead, UNIX makes use of small pluggable components whereby their usage separately is not of great use. But when combined, they can perform powerful operations. Let's take the ps command as an example; ps on its own displays the currently running processes on your UNIX box. It has a decent number of flags that allows you to display many aspects of the process. For example:

The user that started a process
How much CPU each running process is using
What the command used to start the process is and a lot more

The ps command does an excellent job displaying information about the running processes. However, there isn't any ps flag that filters its output. The lack of this functionality is not a missing feature in the tool; this is intentional.

There is another tool that does an excellent job filtering fed into it: grep. So, using the pipe | character, you can filter the output of ps to show only the SSH proesses running on your sustem like this : ps -ef | grep -i ssh. The ps tool is concerned with displaying each and every possible aspect of running processes. The grep command is concerned with offering the ability of filtering text, any text in many different ways.

Because of both UNIX power and simplicity, this principle was used in many other domains in addition to operating systems. In Kubernetes, for example, each container should do only one job and do it well. You might want to ask that what if the container's job requires extra procedures to aid it or enhance it? there is nothing to worry about because the same way we piped the output of the ps command to grep, we can use another container sitting beside the main one in the same Pod. That second container carries out the auxiliary logic needed by the first container to function correctly. That second container is commonly known as Sidecar.

What Does a Sidecar Container Do?

A Pod is the basic atomic unit of deployment in Kubernetes. Typically, a Pod contains a single container. However, multiple containers can be placed in the same Pod. All containers running on the same Pod share the same volume and network interface of the Pod. Actuallay, the Pod itself is a container that executes the pause command. Its sole purpose is to hold the network interfaces and the Linux namespaces to run other containers. A Sidecar container is a second container added to the Pod definition. Why it must be placed in the same Pod is that it needs to use the same resources being used by the main container. Let's have an example to demonstrate the use cases of this pattern.

Scenario: Log-Shipping Sidecar

In this scenario, we have a web server container running the nginx image. The access and error logs produced by the web server are not critical enough to be placed on a Persistent Volume (PV). However, developers need to access to the last 24 hours of logs so they can trace issues and bugs. Therefore we need to ship the access and error logs for the web server to a log-aggregation service. Following the separation of concerns principle, we implement the Sidecar pattern by deploying a second container that ships the error and access logs from nginx. Nginx does one thing, serving the web pages. The second container also specializes in its task; shipping logs. Since containers are running on the same Pod, we can use a shared emptyDir volume to read and write logs. The definition file for such a Pod may look as follows:

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  volumes:
    - name: shared-logs
      emptyDir: {}

  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

The above definition is a standard Kubernetes Pod definition except that it deploys two containers to the same Pod. The sidecar container conventionally comes second in the definition so that when you issue the kubectl execute command, you target the main container by default. The main container is an nginx container that's instructed to store its logs on a volume mounted on /var/log/nginx. Mounting a volume at that location prevents Nginx from outputting its log data to the standard output and forces it to write them to access.log and error.log files.

Side Note on Log Aggregation

Notice that the default behaviour of the Nginx image is to store its logs to the standard output to be picked by Dockers' log collector. Docker stores those logs under /var/lib/docker/containers/container-ID/container-ID-json.log on the host machine. With more than one container (from different Pods) running on the same host and using the same location for storing their logs, your can use a DaemonSet to deploy a log-collector container like Filebat or Logstash to collect those logs and send them to a log-aggregator like ElasticSearch. You will need to mount /var/lib/docker/containers as a hostPath volume to the DaemonSet Pod to give the log-collector container access to the logs.

The sidecar container runs with the nginx container on the same Pod. This enables the sidecar container to access the same volume as the web server. In the above example, we used the cat command to simulate sending the log data to a log aggregator every 30 seconds.

Kubernetes Patterns: The Cron Job Pattern

ylcnky — Sun, 16 Jan 2022 20:42:21 +0000

Scheduled Job Challenges

Cron jobs were part of the UNIX system since its early version. When GNU and Linux came into existance, crons were already part of the system. A cron job is simply a command, program, or shell script that is scheduled to run periodically. For example, a program that automatically executes log rotation must be from time to time.

However, as the application grows in scale and high availability is needed, we need our cron jobs to be highly available as well. The following challenges may face this approach:

If we have multiple hosting for high availability, which node handles the cron?
What happens if multiple identical cron jobs run simulataneously?

One possible solution to these challenges is to create a higher level "controller" that manages cron jobs. The controller is installed on each node, and a leader node gets elected. The leader node is the only one that can execute cron jobs. If the node is down. another node gets elected. However, you will need install this controller through a third-party vendor or write your own. Fortunately, you can execute periodic tasks by using Kubernetes CronJob controller, which adds a time dimenstion to the traditional Job controller. In this article, we demonstrate the CronJob type, it use case, and the type of problems it solves.

A Cron Job Example

apiVersion: batch/v1beta1
kind: CronJob
metadata:
 name: sender
spec:
 schedule: "*/15 * * * *"
 jobTemplate:
   spec:
     template:
       spec:
         containers:
         - image: bash
           name: sender
           command: ["bash","-c","echo 'Sending information to API/database'"]
         restartPolicy: OnFailure

The purpose of the above definition file is to create a CronJob resource that sends data to an API or a database every fifteen minutes. We used the echo command from the bash Docker image to simulate the sending action to keep the example simple. Let's see the critical properties in this definition.

.spec.schedule: the schedule parameter defines how frequent the job should run. It uses the same cron format as Linux. If you are not familiar with the cron format, it's straightforward. We have five slots: minutes, hours, days, months, and day of the week. If we want to ignore one of them, we place a start in the slot (*).

You can also use the */ notation to denote every x units. In Out example, */15 means every fifteen minutes, the remaining slots have * so it will run on all hours, all days, all months, and all the days of the week. For more information about the cron format, you can refer to this documentation. Like the Job resource, the CronJob uses a Pod template to define the containers that this Pod hosts and the specs of those containers. .spec.jobTemplate.spec.template.spec.restartPolicy defines whether to restart the job. You can set this value to Never or OnFailure.

Potential Cases for Cron Jobs

My Cron Job Didn't Start On Time:

In some cases, the CronJob may not get triggered on the specified time. In such an event, there are two scenarios:

We need to execute the job didn't start even if it was delayed.
We need to execute the job that didn't start only if a specific time limit was not crossed.

In our first example, the job sends information to an API that expects this information every fifteen minutes. If the data arrives late, it's useless, and the API automatically discards it. The CronJob resource offers the:

.spec.startingDeadlineSeconds
parameter. If the job misses the scheduled time and did not exceed that number of seconds, it should get executed. Otherwise it is executed on the next scheduled time. Notice that if this parameter is not set, the CronJob counts all the missed jobs since the last successful execution and reschedules them with a maximum 100 missed job. If the number of missing jobs exceeds 100, the cron job is not rescheduled.

#### My CronJob is Taking so Long that It Would Span to the Next Execution Time:

If the CronJob takes too long to finish, you may be in a situation wherer another instance of the job kics in on its scheduled time. The CronJob resource offers the .spec.concurrencyPolicy. This parameter gives you the following options:

concurrencyPolicy: Always allows concurrent instances of the same CronJob to run. This is the default behavior.
concurrencyPolicy: Replace if the current job hasn't finished yet, kill it and start the newly scheduled one.
concurrencyPolicy: Forbid when killing a running job is undesirable, we need to let it complete before starting a new one.

#### I Need to Execute the CronJob Only Once:
In Linux, we hav the at command. The at command allows you to reschedule a program to get completed but only once. This functionality can be achieved using the CronJob resource on Kubernetes using the .spec.suspend parameter. When this parameter is set to True, it suspends all subsequent CronJob executions. However, be aware that you must also use the startingDeadlineSeconds with it. The reason is that if you changed the suspend value to False, Kubernetes examines all the missed jobs taht were not executed because of the suspend parameter being on. If the jobs count is less then 100, they get executed. Using the startingDeadlineSconds setting, you can avoid this behavior as it precents missed jobs from getting executed if the pass the defined number of seconds.

#### Does Cron Job Keep a History of the Jobs that Succeeded and Failed ?
Most of the times, you need to know whaat happened when the cron job last ran. If a database update didn't occur, an API server wasn't updated or any other action that was supposed to happen as a result of the CronJob running, you would need to know why. By default, CronJob remembers the last three succeeded jovs and the last failed one. However, those values can be changed to you preference by setting the following parameters:

.spec.succesfulJobsHistoryLimit: if not set, it defaults to 3. It specifies the number of successful jobs to keep in history.
.spec.failedJobHistoryLimit: if not set, it defaults to 1. It specifies the number of failed jobs to keep in history.

Kubernetes Capacity Planning

ylcnky — Sun, 16 Jan 2022 20:29:17 +0000

Kubernetes Patterns: Capacity Planning

An excellent cloud-native application design should declare any specific resource that it needs to operate correctly. Kubernetes uses those requirements to make the most efficient decisions to ensure maximum performance and availability of the application. Additionally, knowing the application requirements firsthand allows you to make cost-effective decisions regarding the hardware specifications of the cluster nodes.

In this post, we will explore the best practices to declare storate, CPU, and memory resources needs. We will also discuss how Kubernetes behaves if you don't specify some of these dependencies.

Storage Dependency

Let's explore the most common runtime requirement of an application: Persisten Storage. By default, any modifications made to the filesystem of a running container are lost when the container is restarted. Kubernetes provides two solutions to ensure that changes persist: èmptyDir and Persistent Volume (PV).

Using PV, you can store data that does not get deleted even if the whole Pod was terminated or restarted. There are several methods by which you can provision a backend storage to the cluster. It depends on the environment where the cluster is hosted (on-prem or in cloud-provider). In the following exercise, we use the host's disk as the PV backend storage. Provisioning storate using PVs involves two steps:

Creating the PV: this is the disk on which Pod claim space. This step differs depending on the hosting environent.
Creating a Persistent Volume Claim (PVC): this is where you actually provision the storage for the Pod by claiming space on the PV.

First, let's create a PV using the host's local disk. Create the following PV.yml file:

apiVersion: v1
kind: PersistentVolume
metadata:
 name: hostpath-vol
spec:
 storageClassName: local
 capacity:
   storage: 1Gi
 accessModes:
   - ReadWriteOnce
 hostPath:
   path: "/tmp/data"

This definition creates a PV that uses the host disk as the backend storate. The volume is mounted on /tmp/data directory on the host. We need to crete this directory before applying the configuration

$ mkdir /tmp/data
$ kubectl apply -f PV.yaml
persistentvolume/hostpath-vol created

Now, we can create a PVC and avail it to our Pod to stora data through a mount point. The following definition file creates both PVC and a Pod that uses it.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: local
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 100Mi
---
apiVersion: v1
kind: Pod
metadata:
 name: pvc-example
spec:
 containers:
 - image: alpine
   name: pvc-example
   command: ['sh', '-c', 'sleep 10000']
   volumeMounts:
     - mountPath: "/data"
       name: my-vol

 volumes:
   - name: my-vol
     persistentVolumeClaim:
      claimName: my-pvc

Applyting this definiiton file creates the PVC followed by the Pod.

$ kubectl apply -f pvc_pod.yaml
persistentvolumeclaim/my-pvc created
pod/pvc-example created

Any data that gets created or modified on /data inside the container will be persisted to the host's disk. You can check that by logging into the container, creating a file under /data, restarting the Pod and then ensuring the file still exists on the Pod. You can also notice that files created in /tmp/data are immediately available to the Pod and its containers.

The `hostPort` Dependency

If you are using the hostPort option, you are explicitly allowing the internal container port to be accessible from outside the host. A Pod that uses hostPort cannot have more than one replica on the same host because of port conflicts. If no node can provide the required the port, then the Pod using in the `hostPort option will never get scheduled. Additionally, this creates a one-to-one relationship between the Pod and its hosting node. So, in a cluster with four nodes, you can only have a maximum of four Pods that use the hostPort option.

Configuration Dependency

Almost all application are designed so that they can be customized through variables. For example, MySQL needs at least the initial root credentials. Kubernetes provides configMaps for injecting variables to containers inside Pods and Secrets for supplying confidentaial variables like account credentials. Let's have a quick example on how to use configMaps to provision variables to a Pod:
`yml
kind: ConfigMap
apiVersion: v1
metadata:
name: myconfigmap
data:
# Configuration values can be set as key-value properties
dbhost: db.example.com

dbname: mydb

kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:

name: mycontainer image: nginx envFrom:
- configMapRef: name: myconfigmap Now let's apply this configuration and ensure that we can use the environment variables in our container.console $ kubectl apply -f pod.yml configmap/myconfigmap created pod/mypod created $ kubectl exec -it mypod -- bash root@mypod:/# echo $dbhost db.example.com root@mypod:/# echo $dbname mydb However, this creates a dependency of its own: if theconfigMap` was not available, the container might not work as expected. In our example, if this container and application needs a constant database connection to work, then if it failed to obtain the database name and host, it may not work at all. The same thing holds for Secrets, which must be available firsthand before any client containers can get spawned.

Resource Dependencies

So far we discussed the different runtime dependencies that affect which node will the Pod get scheduled and the various prerequisities that must be availed for the Pod to function correctly. However, you must also take into consideration that capacity requirement of the container.

Controllable and Uncontrollable Resources

When designing an application, we need to be aware of the type of resources that this application may consume. Generally, resources can be classified into two main categories:

Sharable: those are the resources that can be shared among different consumers and, thus, limited when required. Examples of this are CPU and network bandwidth
Non-shareable: resources that cannot be shared by nature. For example, memory. If a container tries to use more memory than its allocation, it will get killed.

Declaring Pod Resource Requirements

The distinction between both resources types is crucial for a good design. Kubernetes allows you to declare the amount of CPU and memory the Pod requires to function. There are two parameters that you can use for this declaration:

requests: this is the minimum amount of resources taht the Pod needs. For example, you may already have the knowledge that the hosted application will fail to start if it does not have access to at least 512 MB memory.
limits: the limits define the maximum amount of resources that you need to supply for a given Pod.

Let's have a quick example for a scenario application that needs at least 512 MB and 0.25% of a CPU core to run. The definition file for such a Pod may look like this:
`yml
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:

name: mycontainer image: myapp resources: requests: cpu: 250m memory: 512Mi limits: cpu: 500m memory: 750Mi ` When the scheduler manages to deploy this Pod, it will search for a node that has at least 512MB of memory free. If a suitable node was found, the Pod gets scheduled on it. Otherwise, the Pod will never get deployed. Notice that only the requiest field is considered by the scheduler when determining where to deploy the Pod.

How Are the Resource Requests and Limits Calculated ?

Memory is calculated in bytes, but you are allowed to use units like Mi and Gi to specify the requested amount. Notice that you should not specify a memory limit that is higher than the amount of memory on your nodes. If you did, the Pod would never get scheduled. Additionally, since memory is a non-sharable resource as we discussed, if a container tried to request more memory than the limit, it will get killed. Pods that are created through a higher controller like a ReplicaSet or a Deployment have their containers restarted automatically when they crash or get terminated. Hence, it is always recommented that you create Pods through a contoller.

CPU is calculated through millicores. 1 core = 1000 millicores. So if you expect your container needs at least half a core to operate, you set the request to 500m. However, since CPU belongs to sharable resources when the container requests more CPU than the limit, it will not get terminated. Rather, the Kubelet throttles the container, which may negatively affect its performance. It is advised here that you use liveness and readiness probes to ensure that you application latency does not affect your business requirements.

What Happens When You (not) Specify Requests and Limits ?

Most of the Pod definitions examples ignore the requests and limits parameters. You are not strictly required to include them when designing your cluster. Adding or ignoring requests and limits affects the quality of service that the Pod receives as follows:

Lowest Priority Pods: when you do not specify requests and limits, the Kubelet will deal with your Pod in a best-effort manner. The Pod, in this case, has the lowest priority. If the node runs our of non-shaerable resources, the best-effort Pods are the first to get killed.
Medium Priority Pods: if you define both parameters and set the requests to be less than the limit, then Kubernetes manages your Pod in the Burstable manner. When the node runs out of non-sharable resources, the Burstable Pods will get killed only when there are not more best-effort Pods running.
Highest Priority Pods: your Pod will be deemed as of the most top priority when you set the requests and the limits to equal values. It's as if you are saying. I need this Pod to consume no less and no more than X memory and Y CPU. In this case, and in the event of the node running our of shaerable resources, Kubernetes does not terminate those Pods until the best-effort, and the burstable Pods are terminated. Those are the higest priority Pods.

We can summarize how the Kubelet deals with Pod priority as follows:

Method	Priority	Request	Limit
Best-effort	Lowest	None	None
Burstable	Medium	X	Y (higher than X)
Guaranteed	High	X	X

Pod Priority and Preemption

Sometimes you may need to have more fine-grained control over which of your Pods get evicted first in the event of resources starvation. You can guarantee that a given Pod get evicted last if you set the request and limit to equal values. However, consider a scenario when you have two Pods, one hosting your core applicationa nd another hosting its database. You need those Pods to have the highest priority among other Pods that coexist with them. But you have an additional requirement: you want the application Pods to get evicted berfore the database ones do. Fortunately Kubernetes has a feature that addresses this need: Pod Priority and preemption. So, back to out example scenario, we need two high prority Pods, yet one of them is more important than the other. We start by creating a PriorityClass than a Pod that uses this PriorityClass:
`yml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority

value: 1000

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:

image: redis name: mycontainer priorityClassName: high-priority ` The definition file creates two objects: the PriorityClass and a Pod. ## How Pods Get Scheduled Given Their PriorityClass Value ?

When we have multiple Pods with Different PriorityClass values, the admission contoller starts by sorting Pods according to their priority. Highest priority Pods (those having the highest PriorityClass numbers) get scheduled first as long as no other constraints are preventing their scheduling.

Now, what happens if there are no nodes with available resources to schedule a high priority Pod? The scheduler will evict (preempt) lower priority Pods from the node to give enough room for the higher priority ones. The scheduler will continue lower-priority Pods until there is enough room to accommodate the more upper Pods. This feature helps you when you design the cluster so that you ensure that the highest priority Pods (ex. the core application and database) are never evicted unless no other option is possible. At the same time, they also get scheduled first.

Things to Consider in your Design When Using QoS and Pod Priority

You may be asking what happens when you use resources and limits (QoS) combined with the PriorityClass parameter. Do they overlap or override each other? Followings can be essential things to note when influencing the schedule decisions:

The Kubelet uses QoS to control and manage the node's limited resources among the Pods. QoS eviction happens only when the node starts to run out of shareable resources. The Kubelet considers QoS before considering Preemption priorities.
The scheduler considers the PriorityClass of the Pod before the QoS. It does not attempt to evict Pods unless higher-priority Pods need to be scheduled and the node does not have enough room for them.
When the scheduler decides to preempt lower-priority pods, it attempts a clean and respects the grace period. However, it does not honor PodDistruptionBudget, which may lead to distupting the cluster quorum of several low priority Pods.

Kubernetes Patterns: The Adapter Pattern

ylcnky — Sun, 16 Jan 2022 20:15:45 +0000

Kubernetes Patterns: The Adapter Pattern

All containerized applications are able to communicate with each other through a well-defined protocol, typically HTTP. Each application has a set of endpoints that expect an HTTP verb to do a specific action. It is the responsibility of the client determine how to communicate with the server application. However, you could have a service that expects a specific response from any application. The most common example of this service type is Prometheus. Prometheus is a very well-known monitoring application that checks not only if an application is working, but also if it is working as expected or perfectly.

Prometheus works by querying and endpoint exposed by the target application. The endpoint must return the diagnostic data in a format that Prometheus expects. A possible solution is to configure each application to output its health data in a Prometheus-friendly way. However, you may need to switch your monitoring solution to another tool that expects another format. Changing the application code each time you need a health-status format is largely ineficient. Following the Adapter Pattern, we can have a sidecar container in the same Pod as the app's container. The only purpose of the sidecar (the adapter container) is to "translate" the output from the application's endpoint to a format that Prometheus (or the client tool) accepts and understands.

Scenario: Using an Adapter Container with Nginx

Nginx has an endpoint that is used for querying the web server's status. In this scenario, we add an adapter container to transform this endpoint's output to the required format for Prometheus. First, we need to enable this endpoint on Nginx. To do this, we need to make a change to the default.conf file. The following configMap contains the required default.conf file

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  default.conf: |
    server {
      listen       80;
      server_name  localhost;
      location / {
          root   /usr/share/nginx/html;
          index  index.html index.htm;
      }
      error_page   500 502 503 504  /50x.html;
      location = /50x.html {
          root   /usr/share/nginx/html;
      }
      location /nginx_status {
        stub_status;
        allow 127.0.0.1;  #only allow requests from localhost
        deny all;   #deny all other hosts
      }
    }

This is the default default.conf file that ships the nginx Docker image. We define an endpoint /nginx_status that makes use of the stub_status module to display nginx's diagnostic information. Next, let's create the Nginx Pod and the adapter container:

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  volumes:
  - name: nginx-conf
    configMap:
      name: nginx-conf
      items:
      - key: default.conf
        path: default.conf
  containers:
  - name: webserver
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /etc/nginx/conf.d
      name: nginx-conf
      readOnly: true
  - name: adapter
    image: nginx/nginx-prometheus-exporter:0.4.2
    args: ["-nginx.scrape-uri","http://localhost/nginx_status"]
    ports:
    - containerPort: 9113

The Pod definition contains two containers; the nginx container, which acts as the application container, and the adapter container. The adapter container uses the nginx/nginx-prometheus-exporter which does the magic of transforming the metrics that Nginx exposes on /nginx_status following the Prometheus format. If you are interested in seeing the difference between both metrics, do the following

$ kubectl exec -it webserver bash
$ root@webserver:/# apt update && apt install curl -y
Defaulting container name to webserver.
Use 'kubectl describe pod/webserver -n default' to see all of the containers in this pod.
$ root@webserver:/# curl localhost/nginx_status
Active connections: 1
server accepts handled requests
 3 3 3
 Reading: 0 Writing: 1 Waiting: 0
 $ root@webserver:/# curl localhost:9313/metrics
 curl: (7) Failed to connect to localhost port 9313: Connection refused
root@webserver:/# curl localhost:9113/metrics
# HELP nginx_connections_accepted Accepted client connections
# TYPE nginx_connections_accepted counter
nginx_connections_accepted 4
# HELP nginx_connections_active Active client connections
# TYPE nginx_connections_active gauge
nginx_connections_active 1
# HELP nginx_connections_handled Handled client connections
# TYPE nginx_connections_handled counter
nginx_connections_handled 4
# HELP nginx_connections_reading Connections where NGINX is reading the request header
# TYPE nginx_connections_reading gauge
nginx_connections_reading 0
# HELP nginx_connections_waiting Idle client connections
# TYPE nginx_connections_waiting gauge
nginx_connections_waiting 0
# HELP nginx_connections_writing Connections where NGINX is writing the response back to the client
# TYPE nginx_connections_writing gauge
nginx_connections_writing 1
# HELP nginx_http_requests_total Total http requests
# TYPE nginx_http_requests_total counter
nginx_http_requests_total 4
# HELP nginx_up Status of the last metric scrape
# TYPE nginx_up gauge
nginx_up 1
# HELP nginxexporter_build_info Exporter build information
# TYPE nginxexporter_build_info gauge
nginxexporter_build_info{gitCommit="f017367",version="0.4.2"} 1

So we logged into the webserver Pod, installed curl to be able to establish HTTP requests, and examined the /nginx_status endpoint and the exporter's one (located under: 9113/metrics). Notice that in both requests, we used localhost as the server address. That's because both containers are running in the same Pod and using the same loopback address.

Forem: ylcnky

Kubernetes Patters: The Sidecar

What Does a Sidecar Container Do?

Scenario: Log-Shipping Sidecar

Side Note on Log Aggregation

Kubernetes Patterns: The Cron Job Pattern

Scheduled Job Challenges

A Cron Job Example

Potential Cases for Cron Jobs

My Cron Job Didn't Start On Time:

Kubernetes Capacity Planning

Kubernetes Patterns: Capacity Planning

Storage Dependency

The hostPort Dependency

Configuration Dependency

dbname: mydb

Resource Dependencies

Controllable and Uncontrollable Resources

Declaring Pod Resource Requirements

How Are the Resource Requests and Limits Calculated ?

What Happens When You (not) Specify Requests and Limits ?

Pod Priority and Preemption

value: 1000

Things to Consider in your Design When Using QoS and Pod Priority

Kubernetes Patterns: The Adapter Pattern

Kubernetes Patterns: The Adapter Pattern

Scenario: Using an Adapter Container with Nginx

The `hostPort` Dependency