DEV Community: Milad Roudgarian

Kubernetes Common Resource Types

Milad Roudgarian — Fri, 29 Mar 2024 18:35:43 +0000

Understanding Kubernetes resource types is essential for building scalable, resilient, and secure applications on Kubernetes. By leveraging the right combination of resource types, software engineers can design robust architectures, streamline deployments, and optimize resource utilization within their Kubernetes clusters. This is just an explore the most commonly used Kubernetes resource types, their purposes, and how they contribute to the overall architecture of a Kubernetes deployment.

1- Pod

A Pod represents a single instance of a running process in the cluster.
It encapsulates one or more containers that are tightly coupled and share resources, such as networking and storage.
Pods are the smallest deployable units in Kubernetes and can contain one or more application containers.

2- Service

A Service defines a set of Pods and a policy to access them.
It provides a stable, virtual IP address and DNS name for accessing the pods.
Services enable communication between different parts of an application, both within and outside the Kubernetes cluster.

3- ReplicaSet

ReplicaSets ensure that a specified number of pod replicas are running at any given time.
They provide high availability by automatically scaling the number of pod replicas up or down in response to changes in demand or failures.
ReplicaSets are typically used to manage stateless applications that can scale horizontally.

4- Deployment

Deployments provide declarative updates to Pods and ReplicaSets.
They manage the lifecycle of Pods, including creating, updating, and deleting them as necessary.
Deployments enable rolling updates and rollbacks, ensuring zero downtime during application updates.

5- StatefulSet

StatefulSets manages the deployment and scaling of a set of Pods with unique identities.
They provide stable, unique network identifiers (hostnames) and persistent storage for each Pod.
StatefulSets are used for stateful applications that require stable network identities and persistent storage.

6- DaemonSet

DaemonSets ensure that all (or some) nodes in the cluster run a copy of a specified Pod.
They are typically used to deploy system daemons or background services, such as log collectors or monitoring agents, on every node in the cluster.

7- Job

Jobs create one or more Pods and ensure that a specified number of them successfully terminate.
They are used for short-lived, batch processing tasks, such as data import/export or periodic cleanup operations.

8- CronJob

CronJobs creates Jobs on a schedule, similar to cron in Unix-like operating systems.
They are used for recurring tasks, such as backups, data synchronization, or report generation, that need to run at specific intervals.

9- Namespace

Namespaces provide a way to divide cluster resources between multiple users, teams, or projects.
They provide scope for resources, allowing different groups to work independently within the same Kubernetes cluster.
Namespaces help organize and isolate resources, improving manageability and security.

10- ConfigMap

ConfigMaps stores configuration data in key-value pairs that can be mounted as files or environment variables in a Pod.
They are used to decouple configuration from application code and enable configuration management in a Kubernetes-native way.

11- Secret

Secrets store sensitive data, such as passwords, API keys, or TLS certificates, in an encrypted format.
They are similar to ConfigMaps but are intended for confidential or security-sensitive information.
Secrets are often used to store credentials or other sensitive data required by applications running in Pods.

12- PersistentVolume

Persistent volumes represent a piece of storage in the cluster that has been provisioned by an administrator.
They provide an abstraction layer for storage resources, allowing Pods to request and consume storage without needing to know the details of the underlying infrastructure.

13- PersistentVolumeClaim

PersistentVolumeClaims request storage resources from PersistentVolumes.
They provide an abstraction layer for storage provisioning, allowing developers to request storage resources of a specific type and size without needing to know the details of the underlying infrastructure.

14- ServiceAccount

ServiceAccounts provide an identity for processes running in a Pod.
They are used to authenticate Pods with the Kubernetes API server and control access to cluster resources.

15- Role

Roles define a set of permissions within a Namespace.
They specify what actions are allowed on which resources within the Namespace, such as creating, updating, or deleting Pods, Services, or ConfigMaps.

16- ClusterRole

ClusterRoles define a set of permissions across the entire cluster.
They are similar to Roles but apply globally to all Namespaces in the cluster.

17- RoleBinding

RoleBindings bind a Role to a set of users or groups within a Namespace.
They specify which users or groups have access to the permissions defined by the Role.

18- ClusterRoleBinding

ClusterRoleBindings bind a ClusterRole to a set of users or groups across the entire cluster.
They specify which users or groups have access to the permissions defined by the ClusterRole.

19- Ingress

Ingress manages external access to Services in the cluster, typically HTTP or HTTPS traffic.
It provides a centralized point of entry for incoming requests and allows for advanced routing and load balancing based on URL paths, hostnames, or other criteria.

20- ResourceQuota

ResourceQuotas specify constraints on resource consumption (CPU, memory, storage, etc.) within a Namespace.
They limit the amount of resources that can be used by Pods, Services, and other objects within the Namespace, helping to prevent resource exhaustion and ensure fair resource allocation.

These are just some of the common "kind" field items in Kubernetes. There are many other resource types available, each serving different purposes in the Kubernetes ecosystem.

Distributing Git Repository Across Multiple Origins

Milad Roudgarian — Tue, 12 Mar 2024 11:10:54 +0000

In software development, ensuring backups and efficient collaboration is crucial. Pushing a Git repository to multiple origins facilitates maintaining mirrored copies on various remote repositories like GitHub and GitLab. This approach streamlines the process of propagating changes with a single push command, enabling scenarios such as managing code bases for CI/CD Pipelines or collaborative feature/module sharing among multiple businesses.

If it happened to you that you wanted to push your project to several different remotes but faced problems and could not do it, I suggest you read this article on my LinkedIn.

https://www.linkedin.com/pulse/distributing-git-repository-across-multiple-origins-milad-roudgarian-jnanf/?trackingId=PXAlfF59QSWroJKzTvxwFg%3D%3D

Common Status Codes in gRPC and HTTP

Milad Roudgarian — Sun, 18 Feb 2024 18:32:49 +0000

HTTP status codes are integral to REST API applications and microservices. With the introduction of the gRPC framework, applications gained the ability to redefine their roles based on traditional protocol/RPC standards.

Effective error handling is crucial, prompting the need to convert gRPC status codes into their HTTP equivalents for seamless processing by REST API services. The table below outlines the corresponding status codes, enhancing the development workflow. For more in-depth information, refer to the gRPC-GateWay repository.

|-----------------------------|---------------------------|
| gRPC Status Code            | HTTP Status Code          |
|-----------------------------|---------------------------|
|`OK` (Code: 0)               | 200 OK                    |
|`CANCELLED` (Code: 1)        | 499 Client Closed Request |
|`UNKNOWN` (Code: 2)          | 500 Internal Server Error |
|`INVALID_ARGUMENT` (Code: 3) | 400 Bad Request           |
|`DEADLINE_EXCEEDED` (Code: 4)| 504 Gateway Timeout       |
|`NOT_FOUND` (Code: 5)        | 404 Not Found             |
|`ALREADY_EXISTS` (Code: 6)   | 409 Conflict              |
|`PERMISSION_DENIED` (Code: 7)| 403 Forbidden             |
|`RESOURCE_EXHAUSTED`(Code:8) | 429 Too Many Requests     |
|`FAILED_PRECONDITION`(Code:9)| 400 Bad Request           |
|`ABORTED` (Code: 10)         | 409 Conflict              |
|`OUT_OF_RANGE` (Code: 11)    | 400 Bad Request           |
|`UNIMPLEMENTED` (Code: 12)   | 501 Not Implemented       |
|`INTERNAL` (Code: 13)        | 500 Internal Server Error |
|`UNAVAILABLE` (Code: 14)     | 503 Service Unavailable   |
|`DATA_LOSS` (Code: 15)       | 500 Internal Server Error |
|-----------------------------|---------------------------|

Note that some gRPC status codes may not have a direct HTTP equivalent, and the mappings are based on best-fit scenarios. Additionally, gRPC status codes provide more granular information about the status of a request compared to HTTP status codes.

Git Submodule: Managing Dependencies with Precision

Milad Roudgarian — Thu, 01 Feb 2024 09:30:09 +0000

Assume that many files are shared between countable microservices and are crucial for the project life-cycle. Such as the .proto file that could be used in both the gateway service and many other related services.
As an approach, you can use a symbolic link to have access, but many conflicts like dependency on the file system structure occur. If directories change or if you move your project, links might break. Consider using Git submodules or separate Git repositories for shared proto files provides versioning and easier management for this dummy scenario.

What is the Git Submodule?

Git submodules facilitate the inclusion of one Git Repository as a Subdirectory within another Git Repository.
Essentially, a Git submodule is a reference to a specific snapshot of another repository. This functionality
allows a Git repository to integrate external code, retaining the ability to track its version history.

Git submodules are beneficial in scenarios where strict version control of external dependencies is crucial. Common use cases include:

Ensuring Stability: If an external component evolves rapidly or anticipated changes may disrupt the API, you can secure the code by fixing it to a specific commit for stability.
Managing Vendor Dependencies: For components with infrequent updates, Git submodules are useful for tracking them as vendor dependencies.
Third-Party Integration: Delegating a project segment to a third party becomes more manageable when you want to incorporate their work at a specific time or release, especially when updates are sporadic.

Git Submodule Practical Commands

These are basic commands, and depending on your specific use case, you might need to explore more advanced submodule commands.
To dig deeper into the concept, reviewing the Git Official Documentation is recommended.

Add a Submodule:

git submodule add <repository_URL> <path>

Example:

git submodule add https://github.com/example/repo.git vendor/repo

Initialize Submodules After Cloning a Repository:

git submodule update --init --recursive

Update Submodules: To fetch the latest changes from the submodule repositories.

git submodule update --remote

Clone a Repository with Submodules: To clone a repository and its submodules.

git clone --recursive <repository_URL>

Initialize Submodules After Cloning (Older Git Versions): For Git versions older than 1.6.5.

git submodule init

git submodule update

Fetch Submodule Changes: To pull changes from the master branch of each submodule.

git submodule deinit -f -- <submodule_path>

git rm -f <submodule_path>

rm -rf .git/modules/<submodule_path>

Remove a Submodule: After running these commands, you also need to commit the changes.

git submodule deinit -f -- <submodule_path>

git rm -f <submodule_path>

rm -rf .git/modules/<submodule_path>

Update Submodule URL: If the URL of a submodule has changed, you need to run this command to update the configuration.

git submodule sync

Clone Submodule Recursively: To clone a repository and its submodules in one step.

git clone --recursive <repository_URL>

Custom Commands
You can use the git submodule foreach command to run custom commands on each submodule.

Example:

git submodule foreach 'git checkout master'

This checks out the master branch in each submodule.

Technical solutions are written in Golang

Milad Roudgarian — Sat, 13 Jan 2024 14:51:26 +0000

Suggest you review the common technical solutions written in Golang on GitHub Repositories I encountered to manage my daily tasks. Thus, most of the best practices are available there.

1- The AWS Provider allows Terraform to manage AWS resources.

https://github.com/hashicorp/terraform-provider-aws

2- The Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system.

https://github.com/prometheus/prometheus

3- The imgproxy, a fast and secure standalone server for resizing and converting remote images.

https://github.com/imgproxy/imgproxy

4- The CoreDNS is a DNS server/forwarder, written in Go, that chains plugins. Each plugin performs a (DNS) function.

https://github.com/coredns/coredns

5- The Gitea, is the Git repository manager with the easiest, fastest, and most painless way of setting up a self-hosted Git service.

https://github.com/go-gitea/gitea

6- The MinIO is a High-Performance Object Storage released under GNU Affero General Public License v3.0.

https://github.com/minio/minio