cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

cross-posted from: https://lemmy.run/post/10475

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

Testing Service Accounts in Kubernetes

Service accounts in Kubernetes are used to provide a secure way for applications and services to authenticate and interact with the Kubernetes API. Testing service accounts ensures their functionality and security. In this guide, we will explore different methods to test service accounts in Kubernetes.

1. Verifying Service Account Existence

To start testing service accounts, you first need to ensure they exist in your Kubernetes cluster. You can use the following command to list all the available service accounts:

kubectl get serviceaccounts

Verify that the service account you want to test is present in the output. If it's missing, you may need to create it using a YAML manifest or the kubectl create serviceaccount command.

2. Checking Service Account Permissions

After confirming the existence of the service account, the next step is to verify its permissions. Service accounts in Kubernetes are associated with roles or cluster roles, which define what resources and actions they can access.

To check the permissions of a service account, you can use the kubectl auth can-i command. For example, to check if a service account can create pods, run:

kubectl auth can-i create pods --as=system:serviceaccount:<namespace>:<service-account>

Replace <namespace> with the desired namespace and <service-account> with the name of the service account.

3. Testing Service Account Authentication

Service accounts authenticate with the Kubernetes API using bearer tokens. To test service account authentication, you can manually retrieve the token associated with the service account and use it to authenticate requests.

To get the token for a service account, run:

kubectl get secret <service-account-token-secret> -o jsonpath="{.data.token}" | base64 --decode

Replace <service-account-token-secret> with the actual name of the secret associated with the service account. This command decodes and outputs the service account token.

You can then use the obtained token to authenticate requests to the Kubernetes API, for example, by including it in the Authorization header using tools like curl or writing a simple program.

4. Testing Service Account RBAC Policies

Role-Based Access Control (RBAC) policies govern the access permissions for service accounts. It's crucial to test these policies to ensure service accounts have the appropriate level of access.

One way to test RBAC policies is by creating a Pod that uses the service account you want to test and attempting to perform actions that the service account should or shouldn't be allowed to do. Observe the behavior and verify if the access is granted or denied as expected.

5. Automated Testing

To streamline the testing process, you can create automated tests using testing frameworks and tools specific to Kubernetes. For example, the Kubernetes Test Framework (KTF) provides a set of libraries and utilities for writing tests for Kubernetes components, including service accounts.

Using such frameworks allows you to write comprehensive test cases to validate service account behavior, permissions, and RBAC policies automatically.

Conclusion

Testing service accounts in Kubernetes ensures their proper functioning and adherence to security policies. By verifying service account existence, checking permissions, testing authentication, and validating RBAC policies, you can confidently use and rely on service accounts in your Kubernetes deployments.

Remember, service accounts are a critical security component, so it's important to regularly test and review their configuration to prevent unauthorized access and potential security breaches.

Author: Sanghamitra

East and west: Gujarat and Odisha celebrate the Rathayatra of Lord Jagannath with pomp and splendour

Today is Ashadha Shukla Dwitiya, the auspicious day for Lord Jagannath's Rathayatra every year. Two Indian states, located on the two opposite coasts of the grand nation, are celebrating the festival with much fervor and grandeur.

Today is Ashadha Shukla Dwitiya, the auspicious day for Lord Jagannath’s Rathayatra every year. Two Indian states, located on the two opposite coasts of the grand nation, are celebrating the festival with much fervor and grandeur.

Odisha Rathayatra

Odisha, the home abode of Lord Jagannath, has been celebrating the Rathayatra festival for centuries now. The grand Jagannath Temple at Puri, constructed in the 12th century organizes the world’s largest and oldest Rathayatra festival every year in the ‘Bada Danda’ in Puri.

The three grand chariots await outside the Singhadwara of the Temple on the day of the Rathayatra. The construction of the chariots starts on the day of Akshaya Tritiya, and designated carpenters, known as ‘Maharanas’ make the chariots. The colour schemes, and design of the chariots are fixed for each of the three Gods.

Lord Jagannatha’s chariot is called ‘Nandighosha’, Lord Balabhadra’s chariot is called ‘Taladhwaja’ and Devi Subhadra’s chariot is called ‘Debadalana’. Lord Sudarshana rides in the Debadalana too.

The process of bringing the holy Trinity out from their pedestal in the temple to their respective chariots is called ‘Pahandi’.

After the Gods are seated in their respective chariots, the Gajapati Maharaj, the traditional ruler of Kalinga, performs the ritual of ‘Chhera Panhara’. It is the ritual of sweeping the chariots with a golden broom. It signifies the belief that the Gajapati Maharaj is the servant of Lord Jagannath and rules in his name.

The Chhera Panhara ritual has another significance in Odia folklore and literary tradition. Odia epic ‘Kanchi Kaveri Upakhyana’ describes Purushottama Deva’s campaign to win kingdoms in the south of Kalinga. Purushottama Deva was insulted by Kanchi ruler Saluva Narasingha Deva because the former wanted to marry the latter’s daughter Padmavati. Saluva Narasingha Deva had declared that he would rather get his daughter married to a poor sweeper than allow her to marry the Kalinga Gajapati.

Purushottama Deva, fumed at the insult, had attacked Kanchi and eventually won with direct help from Lord Jagannatha and his brother Lord Balabhadra. After bringing Padmavati to Kalinga, he was yet to forget the insult. So he had declared that Padmavati will be married off to a sweeper, just as her father wanted.

However, the clever ministers of Purushottama Deva knew that the Kanchi princess deserves to marry the Gajapati, and Kalinga deserves a queen of unparalleled beauty and qualities that she possessed. So on the day of Rathayatra, when Purushottama Deva was performing the sweeping ritual, they brought the Kanchi princess on board the chariot, and she put a garland on the neck of the Gajapati, just when he held a broom in his hand, literally being a ‘sweeper’.

Purushottama Deva had loved the princess and there was no way he could be angry now, after being married to her in the presence of Lord Jagannatha himself.

Thus, the ministers avoided their king’s wrath and made him see reason by forgetting his anger. The story can be read in detail here.

In Puri’s Rathayatra, the Gods visit the Gundicha Temple and stay there for 9 days. Then they return to their own Temple, that Yatra is called ‘Bahuda Yatra’.

Gujarat Rathayatra

Gujarat is home to Dwaraka, Lord Krishna’s kingdom. Like Odisha, it too has a deep Vaishnava tradition. The state has been celebrating Rathayatra for nearly a century and a half.

It is celebrated as a ‘Lokotsav’ or a public festival in Gujarat. Though many cities have their own Rathyatra, Ahmedabad hosts the grandest and biggest event. The CM performs the ‘Pahind Vidhi’ which is similar to the ‘Chhera Panhara’ ritual of Odisha.

In Ahmedabad Rathyaatra, the chariots pass through the different parts of the city. The chariots cover a distance of 14 km and the devotees offer ‘mahabhoj’ to the entire entourage.

Union Minister Amit Shah today performed the mangal aarti at the Jagannath Temple in Ahmedabad before the commencement of Rathayatra. CM Bhupendra Patel performed the ‘Pahind Vidhi’. This is the 146th year of the Ahmedabad Rathayatra.

Gujarat and Odisha are separated by over 1800 km, located on the opposite coasts of India. However, Rathayatra is something that binds the two states together. Each celebration is unique in its style and decorations, but the deep Jagannath Bhakti and the Vaishnava traditions of their people are what bring them close in mind and spirit.

Rathyatra celebrations in these two distant states are another example of how the states of India, despite diverse linguistic and cultural norms, are bound together by strings of Hindu tradition and spirituality.

cross-posted from: https://lemmy.run/post/10221

Author: Jinit Jain

Ahilyabai Holkar, the Maratha Queen like no other who constructed and restored Hindu temples which stand tall even today

*Ahilyabai Holkar is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievement. *

PM Narendra Modi on Monday, December 13, 2021, inaugurated the Kashi Vishwanath Corridor Project in Varanasi, restoring an array of temples to their past glory. With the inauguration of the hallowed temple corridor project, PM Modi has once again burnished his credentials as the most potent preserver of the Hindu heritage in the recent times.

As PM Modi buckles down the task of fulfilling the promises he made while contesting the Lok Sabha elections from Varanasi constituency in 2014, one of them being transforming it into a “city of temples”, he did not fail to acknowledge the role of historical figures who helped in conserving the city’s holy character.

In his inaugural speech, PM Modi paid floral tributes to Ahilyabai Holkar, Maharaja Ranjit Singh among other people, who played a pivotal role in reconstruction and renovation of Kashi Vishwanath in the past.

PM said, “The role of Mata Ahilyabai Holkar in the reconstruction of the temple is noteworthy. Maharaja Ranjit Singh sent 23 man (920 KG) of gold to the temple.” He said after Mata Ahilyabai Holkar, the expansion of the Kashi Vishwanath Dham had happened now.

And not just in words but in deeds too, PM Modi and the Centre paid homage to Maratha Queen Ahilyabai Holkar for her momentous contribution in preserving the heritage of Kashi Vishwanath. A figurine of Maharani Ahilyabai Holkar has been put up at the sprawling campus of the Kashi Vishwanath Dham, which was adorned with flowers for its inauguration on Monday. In addition to this, large posters of the Maratha queen were also held up in the premises of the corridors.

Who was Ahilyabai Holkar?

Ahilyabai Holkar was one of the most well-known queens to have presided over the Maratha Empire in the 18th century. Born in May 1725 in the village of Chaundi, in present-day Ahmednagar district of Maharashtra, Maharani Ahilyabai Holkar was the Holkar Queen of the Maratha Malwa kingdom.

She was not born in the royal lineage and was the hereditary noble Queen of the Maratha Empire. When she was 8-years-old, she was spotted by the acclaimed Lord of the Malwa territory, Malhar Rao Holkar, while she feeding the poor. Struck by her compassion and empathy for the destitute, Malhar Rao betrothed her to his son.

However, she lost her husband in the battle of Kumbher when she was just 29. After her husband’s death, she tried to end her life with the practice of Sati but was stopped by her father-in-law. She later ascended the throne and became the ruler of Indore on 11 December 1767.

In opposition to the prevailing culture of the time which disallowed women from pursuing education, Ahilyabai Holkar was an educated woman. She was homeschooled by her father. Perhaps, it was her education and knowledge that helped her to pull together the kingdom of Malwa after the demise of her husband and father-in-law.

Ahilyabai ruled for nearly three decades and was conferred with the title of ‘The Philosopher Queen’ by a British historian John Keyas. In her praise, he said: “Ahilyabai Holkar, the philosopher-queen of Malwa, had evidently been an acute observer of the wider political scene.”

Ahilyabai Holkar-The pioneer of temple construction and restoration

Though Ahilyabai Holkar was an astute queen and quite adept in handling court matters, she was best known for being the pioneer, builder and preserver of the Hindu temples across the length and breadth of the country. From Somnath in the west, to the Kashi Vishwanath in the east, Holkar dedicated her life towards renovating and reconstructing temples that were victims of the ravages of the time or were subjected to assault and plunder by Muslim invaders.

She built temples at Srinagar, Haridwar, Kedarnath, Badrinath, Rishikesh, Prayaga, Varanasi, Naimisharanya, Puri, Rameshwaram, Somnath, Nasik, Omkareshvar, Mahabaleshwar, Pune, Indore, Srisailam, Udipi, Gokarna, Khatmandu etc. She built and restored temples everywhere across India except for territories controlled by Afghans, Nawabs & the British.

River Ganga holds special importance as per Hindu scriptures. Regarded as sacred by Hindus, the river is embodied as the goddess Ganga in ancient texts and art. The water of river Ganga is considered as holy, with ritual bathing being an integral part of Hindu pilgrimage. The water, reverentially called as gangajal, was also used in various pujas performed in Hindu temples. Ahilyabai Holkar arranged for supplying water from the river Ganga collected at Gangotri to be received by temples across the country, including temples as far away as in Kerala, Tamil Nadu and Karnataka.

The Maratha Queen’s contribution in rebuilding Kashi Vishwanath Temple

She is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas around her kingdom but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievements of all.

Her contribution in restoring Kashi Vishwanath temple was particularly significant. The temple had stood tall for centuries before becoming an eye sour for the Mughals. The Islamic rulers, who were on the mission to destroy anything that was against Islam, saw Kashi Vishwanath Dham as one of the main targets challenging the supremacy of their faith.

On April 18, 1669, Islamic ruler Aurangzeb gave the order to demolish Kashi Vishwanath Temple. In his order, he had written that the temple was the place where “the foolish Pundits teach evil knowledge from junk books.”

On the explicit orders from Mughal emperor Aurangzeb, Kashi Vishwanath Dham, one of the holiest Hindu sites of pilgrimage, was plundered, desecrated, demolished & converted into Gyanvapi Mosque in 1669. The current structure and the form of the Kashi Vishwanath Temple could be attributed to Ahilyabai Holkar, who got the structure reconstructed in 1776. Then in 19th century, Maharaja Ranjit Singh adorned the temple with ‘golden’ shikhar.

Author: Jinit Jain

Ahilyabai Holkar, the Maratha Queen like no other who constructed and restored Hindu temples which stand tall even today

*Ahilyabai Holkar is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievement. *

PM Narendra Modi on Monday, December 13, 2021, inaugurated the Kashi Vishwanath Corridor Project in Varanasi, restoring an array of temples to their past glory. With the inauguration of the hallowed temple corridor project, PM Modi has once again burnished his credentials as the most potent preserver of the Hindu heritage in the recent times.

As PM Modi buckles down the task of fulfilling the promises he made while contesting the Lok Sabha elections from Varanasi constituency in 2014, one of them being transforming it into a “city of temples”, he did not fail to acknowledge the role of historical figures who helped in conserving the city’s holy character.

In his inaugural speech, PM Modi paid floral tributes to Ahilyabai Holkar, Maharaja Ranjit Singh among other people, who played a pivotal role in reconstruction and renovation of Kashi Vishwanath in the past.

PM said, “The role of Mata Ahilyabai Holkar in the reconstruction of the temple is noteworthy. Maharaja Ranjit Singh sent 23 man (920 KG) of gold to the temple.” He said after Mata Ahilyabai Holkar, the expansion of the Kashi Vishwanath Dham had happened now.

And not just in words but in deeds too, PM Modi and the Centre paid homage to Maratha Queen Ahilyabai Holkar for her momentous contribution in preserving the heritage of Kashi Vishwanath. A figurine of Maharani Ahilyabai Holkar has been put up at the sprawling campus of the Kashi Vishwanath Dham, which was adorned with flowers for its inauguration on Monday. In addition to this, large posters of the Maratha queen were also held up in the premises of the corridors.

Who was Ahilyabai Holkar?

Ahilyabai Holkar was one of the most well-known queens to have presided over the Maratha Empire in the 18th century. Born in May 1725 in the village of Chaundi, in present-day Ahmednagar district of Maharashtra, Maharani Ahilyabai Holkar was the Holkar Queen of the Maratha Malwa kingdom.

She was not born in the royal lineage and was the hereditary noble Queen of the Maratha Empire. When she was 8-years-old, she was spotted by the acclaimed Lord of the Malwa territory, Malhar Rao Holkar, while she feeding the poor. Struck by her compassion and empathy for the destitute, Malhar Rao betrothed her to his son.

However, she lost her husband in the battle of Kumbher when she was just 29. After her husband’s death, she tried to end her life with the practice of Sati but was stopped by her father-in-law. She later ascended the throne and became the ruler of Indore on 11 December 1767.

In opposition to the prevailing culture of the time which disallowed women from pursuing education, Ahilyabai Holkar was an educated woman. She was homeschooled by her father. Perhaps, it was her education and knowledge that helped her to pull together the kingdom of Malwa after the demise of her husband and father-in-law.

Ahilyabai ruled for nearly three decades and was conferred with the title of ‘The Philosopher Queen’ by a British historian John Keyas. In her praise, he said: “Ahilyabai Holkar, the philosopher-queen of Malwa, had evidently been an acute observer of the wider political scene.”

Ahilyabai Holkar-The pioneer of temple construction and restoration

Though Ahilyabai Holkar was an astute queen and quite adept in handling court matters, she was best known for being the pioneer, builder and preserver of the Hindu temples across the length and breadth of the country. From Somnath in the west, to the Kashi Vishwanath in the east, Holkar dedicated her life towards renovating and reconstructing temples that were victims of the ravages of the time or were subjected to assault and plunder by Muslim invaders.

She built temples at Srinagar, Haridwar, Kedarnath, Badrinath, Rishikesh, Prayaga, Varanasi, Naimisharanya, Puri, Rameshwaram, Somnath, Nasik, Omkareshvar, Mahabaleshwar, Pune, Indore, Srisailam, Udipi, Gokarna, Khatmandu etc. She built and restored temples everywhere across India except for territories controlled by Afghans, Nawabs & the British.

River Ganga holds special importance as per Hindu scriptures. Regarded as sacred by Hindus, the river is embodied as the goddess Ganga in ancient texts and art. The water of river Ganga is considered as holy, with ritual bathing being an integral part of Hindu pilgrimage. The water, reverentially called as gangajal, was also used in various pujas performed in Hindu temples. Ahilyabai Holkar arranged for supplying water from the river Ganga collected at Gangotri to be received by temples across the country, including temples as far away as in Kerala, Tamil Nadu and Karnataka.

The Maratha Queen’s contribution in rebuilding Kashi Vishwanath Temple

She is fondly remembered for constructing hundreds of temples, ghats, pilgrimage centres, Dharamshalas around her kingdom but rebuilding of Kashi Vishwanath Temple is considered as her greatest achievements of all.

Her contribution in restoring Kashi Vishwanath temple was particularly significant. The temple had stood tall for centuries before becoming an eye sour for the Mughals. The Islamic rulers, who were on the mission to destroy anything that was against Islam, saw Kashi Vishwanath Dham as one of the main targets challenging the supremacy of their faith.

On April 18, 1669, Islamic ruler Aurangzeb gave the order to demolish Kashi Vishwanath Temple. In his order, he had written that the temple was the place where “the foolish Pundits teach evil knowledge from junk books.”

On the explicit orders from Mughal emperor Aurangzeb, Kashi Vishwanath Dham, one of the holiest Hindu sites of pilgrimage, was plundered, desecrated, demolished & converted into Gyanvapi Mosque in 1669. The current structure and the form of the Kashi Vishwanath Temple could be attributed to Ahilyabai Holkar, who got the structure reconstructed in 1776. Then in 19th century, Maharaja Ranjit Singh adorned the temple with ‘golden’ shikhar.

cross-posted from: https://lemmy.run/post/10206

Creating a Helm Chart for Kubernetes

In this tutorial, we will learn how to create a Helm chart for deploying applications on Kubernetes. Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. By using Helm charts, you can define and version your application deployments as reusable templates.

Prerequisites

Before we begin, make sure you have the following prerequisites installed:

• Helm: Follow the official Helm documentation for installation instructions.

Step 1: Initialize a Helm Chart

To start creating a Helm chart, open a terminal and navigate to the directory where you want to create your chart. Then, run the following command:

helm create my-chart

This will create a new directory named my-chart with the basic structure of a Helm chart.

Step 2: Customize the Chart

Inside the my-chart directory, you will find several files and directories. The most important ones are:

• Chart.yaml: This file contains metadata about the chart, such as its name, version, and dependencies.
• values.yaml: This file defines the default values for the configuration options used in the chart.
• templates/: This directory contains the template files for deploying Kubernetes resources.

You can customize the chart by modifying these files and adding new ones as needed. For example, you can update the Chart.yaml file with your desired metadata and edit the values.yaml file to set default configuration values.

Step 3: Define Kubernetes Resources

To deploy your application on Kubernetes, you need to define the necessary Kubernetes resources in the templates/ directory. Helm uses the Go template language to generate Kubernetes manifests from these templates.

For example, you can create a deployment.yaml template to define a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.containerPort }}

This template uses the values defined in values.yaml to customize the Deployment's name, replica count, image, and container port.

Step 4: Package and Install the Chart

Once you have defined your Helm chart and customized the templates, you can package and install it on a Kubernetes cluster. To package the chart, run the following command:

helm package my-chart

This will create a .tgz file containing the packaged chart.

To install the chart on a Kubernetes cluster, use the following command:

helm install my-release my-chart-0.1.0.tgz

Replace my-release with the desired release name and my-chart-0.1.0.tgz with the name of your packaged chart.

Conclusion

Congratulations! You have learned how to create a Helm chart for deploying applications on Kubernetes. By leveraging Helm's package management capabilities, you can simplify the deployment and management of your Kubernetes-based applications.

Feel free to explore the Helm documentation for more advanced features and best practices.

Happy charting!

cross-posted from: https://lemmy.run/post/10206

Creating a Helm Chart for Kubernetes

In this tutorial, we will learn how to create a Helm chart for deploying applications on Kubernetes. Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. By using Helm charts, you can define and version your application deployments as reusable templates.

Prerequisites

Before we begin, make sure you have the following prerequisites installed:

• Helm: Follow the official Helm documentation for installation instructions.

Step 1: Initialize a Helm Chart

To start creating a Helm chart, open a terminal and navigate to the directory where you want to create your chart. Then, run the following command:

helm create my-chart

This will create a new directory named my-chart with the basic structure of a Helm chart.

Step 2: Customize the Chart

Inside the my-chart directory, you will find several files and directories. The most important ones are:

• Chart.yaml: This file contains metadata about the chart, such as its name, version, and dependencies.
• values.yaml: This file defines the default values for the configuration options used in the chart.
• templates/: This directory contains the template files for deploying Kubernetes resources.

You can customize the chart by modifying these files and adding new ones as needed. For example, you can update the Chart.yaml file with your desired metadata and edit the values.yaml file to set default configuration values.

Step 3: Define Kubernetes Resources

To deploy your application on Kubernetes, you need to define the necessary Kubernetes resources in the templates/ directory. Helm uses the Go template language to generate Kubernetes manifests from these templates.

For example, you can create a deployment.yaml template to define a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.containerPort }}

This template uses the values defined in values.yaml to customize the Deployment's name, replica count, image, and container port.

Step 4: Package and Install the Chart

Once you have defined your Helm chart and customized the templates, you can package and install it on a Kubernetes cluster. To package the chart, run the following command:

helm package my-chart

This will create a .tgz file containing the packaged chart.

To install the chart on a Kubernetes cluster, use the following command:

helm install my-release my-chart-0.1.0.tgz

Replace my-release with the desired release name and my-chart-0.1.0.tgz with the name of your packaged chart.

Conclusion

Congratulations! You have learned how to create a Helm chart for deploying applications on Kubernetes. By leveraging Helm's package management capabilities, you can simplify the deployment and management of your Kubernetes-based applications.

Feel free to explore the Helm documentation for more advanced features and best practices.

Happy charting!

Creating a Helm Chart for Kubernetes

In this tutorial, we will learn how to create a Helm chart for deploying applications on Kubernetes. Helm is a package manager for Kubernetes that simplifies the deployment and management of applications. By using Helm charts, you can define and version your application deployments as reusable templates.

Prerequisites

Before we begin, make sure you have the following prerequisites installed:

• Helm: Follow the official Helm documentation for installation instructions.

Step 1: Initialize a Helm Chart

To start creating a Helm chart, open a terminal and navigate to the directory where you want to create your chart. Then, run the following command:

helm create my-chart

This will create a new directory named my-chart with the basic structure of a Helm chart.

Step 2: Customize the Chart

Inside the my-chart directory, you will find several files and directories. The most important ones are:

• Chart.yaml: This file contains metadata about the chart, such as its name, version, and dependencies.
• values.yaml: This file defines the default values for the configuration options used in the chart.
• templates/: This directory contains the template files for deploying Kubernetes resources.

You can customize the chart by modifying these files and adding new ones as needed. For example, you can update the Chart.yaml file with your desired metadata and edit the values.yaml file to set default configuration values.

Step 3: Define Kubernetes Resources

To deploy your application on Kubernetes, you need to define the necessary Kubernetes resources in the templates/ directory. Helm uses the Go template language to generate Kubernetes manifests from these templates.

For example, you can create a deployment.yaml template to define a Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
          ports:
            - containerPort: {{ .Values.containerPort }}

This template uses the values defined in values.yaml to customize the Deployment's name, replica count, image, and container port.

Step 4: Package and Install the Chart

Once you have defined your Helm chart and customized the templates, you can package and install it on a Kubernetes cluster. To package the chart, run the following command:

helm package my-chart

This will create a .tgz file containing the packaged chart.

To install the chart on a Kubernetes cluster, use the following command:

helm install my-release my-chart-0.1.0.tgz

Replace my-release with the desired release name and my-chart-0.1.0.tgz with the name of your packaged chart.

Conclusion

Congratulations! You have learned how to create a Helm chart for deploying applications on Kubernetes. By leveraging Helm's package management capabilities, you can simplify the deployment and management of your Kubernetes-based applications.

Feel free to explore the Helm documentation for more advanced features and best practices.

Happy charting!

Transferring Files from Local System to Remote AWS Instance using AWS SSM

Hey everyone! Today, I want to share with you a convenient and efficient way to transfer files from your local system to a remote instance in AWS. We'll be using AWS Systems Manager (SSM), a powerful service that enables remote management of your EC2 instances. Let's get started!

Step 1: Set up AWS SSM

Before we begin, make sure you have AWS CLI installed and configured on your local system. Also, ensure that the target EC2 instance is running and has the SSM Agent installed.

Step 2: Create an S3 Bucket (Optional)

If you want to transfer files using S3 as an intermediate storage location, you can create an S3 bucket in the same AWS region as your EC2 instance. This step is optional if you prefer transferring files directly from your local system to the remote instance without using S3.

Step 3: Prepare the File for Transfer

Locate the file you want to transfer on your local system and ensure it is accessible.

Step 4: Initiate the File Transfer

Open a terminal or command prompt on your local system and run the following AWS CLI command to initiate the file transfer:

aws ssm send-command --instance-ids <INSTANCE_ID> --document-name "AWS-RunShellScript" --parameters "commands=['aws s3 cp /path/to/local/file s3://your-bucket-name/file']" --output text

Replace <INSTANCE_ID> with the instance ID of your target EC2 instance. If you opted to use S3, replace /path/to/local/file with the actual path to the file on your local system and your-bucket-name/file with the S3 bucket and file location.

Step 5: Verify the File Transfer

To verify the successful transfer, you can either log in to your EC2 instance and check the destination path or use the AWS CLI command to download the file from S3 to your EC2 instance:

aws ssm send-command --instance-ids <INSTANCE_ID> --document-name "AWS-RunShellScript" --parameters "commands=['aws s3 cp s3://your-bucket-name/file /path/on/ec2/instance']" --output text

Again, replace <INSTANCE_ID> with your instance ID and adjust the S3 and destination paths accordingly.

That's it! You have successfully transferred a file from your local system to a remote instance in AWS using AWS SSM. This method eliminates the need for complex setup or manual file transfers, making it convenient and scalable for large-scale deployments.

Feel free to explore more features of AWS SSM, such as executing commands remotely, managing instances, and automating tasks. Happy file transferring!

cross-posted from: https://lemmy.run/post/10106

Author: Swapnanil Chatterjee

India gifts missile warship INS Kirpan to Vietnam, bolstering maritime security & strategic partnership amid Chinese concerns.

India has gifted an indigenously-built missile warship, INS Kirpan, to its strategic partner Vietnam with the aim of strengthening its reach in the South China Sea. The announcement came after India's Defence Minister, Rajnath Singh, held a meeting with his Vietnamese counterpart, General Phan Van Gang, in the national capital on June 9.

3 Things You Need to Know about Gifting the Kirpan

• The gift of INS Kirpan, an in-service missile corvette, will enhance the Vietnamese People's Navy.
• Vietnam is a vital partner in India's Act East policy, and the gift of Kirpan strengthens this alliance.
• During the visit, Ministers discussed defence cooperation, research, and joint production.

Enhanced maritime security with INS Kirpan

The missile corvette will become the second largest in Vietnam's arsenal and provide a cost-effective solution for Vietnam's coastal defence and patrol operations. With its smaller crew requirements and efficient operation in littoral waters, INS Kirpan offers an efficient and affordable option. It has been designed with multi-purpose capabilities, including anti-ship warfare, anti-submarine warfare, and patrol missions. This versatility allows the Vietnamese Navy to effectively address a wide range of maritime security challenges. Given Vietnam's significant coastal territory, these corvettes can conduct surveillance, enforce maritime law, and respond effectively to threats in nearshore areas. Additionally, acquiring corvettes with capable armament and sensors contributes to regional stability, enabling Vietnam to maintain a credible defence posture and engage in cooperative maritime security efforts with neighbouring countries, fostering stability and cooperation in the region.

Deepening mutual cooperation for further growth

This gesture also signifies the deepening alliance between Vietnam and India, which has been steadily growing over the past decade. The Ministry of Defense's official release stated, "Both Ministers identified means to enhance existing areas of collaboration, especially in the field of defence industry cooperation, maritime security, and multinational cooperation." The officials also discussed defence research and joint production during the Vietnamese defence minister's visit to the Defense Research and Development Organization (DRDO) headquarters.”

Kirpan Strengthens India's 'Look East' Policy

During General Phan Van Gang's visit to India, a solemn wreath-laying ceremony was held at the National War Memorial, where he paid homage to the fallen heroes. In the future, the collaboration can extend beyond defence equipment and encompass joint exercises, information sharing, and capacity building.