Kubernetes Persistent Volumes NFS(AWS|EKS|EFS Storage Class|EFS Provisioner|ReadWriteMany)

Kubernetes Persistent Volumes NFS tutorial will cover creating and attaching NFS volumes to Kubernetes pods. We are going to create a network file system in AWS which is called EFS. We will create a Kubernetes NFS provisioner and provide an EFS IP address. Also, we will create a storage class based on that provisioner. Finally, we will create a persistent volume claim with the ReadWriteMany attribute and mount it to separate applications to test shared access to that volume.

Did I help you out?
☕ Buy Me a Coffe: https://www.buymeacoffee.com/antonputra
🔴 Add me on LinkedIn: https://www.linkedin.com/in/anton-putra

=========
⏱️TIMESTAMPS⏱️
0:00 Intro
2:15 Create EFS File System
6:04 Create Kubernetes NFS Provisioner
12:35 Create EFS Storage Class EKS
18:44 Create NFS Persistent Volume Claim
22:25 Share ReadWriteMany Volume with 2 Apps

=========
Source Code
📚 - Instructions: https://antonputra.com
🖥️ - GitHub: https://github.com/antonputra/tutorials/tree/main/lessons/041

=========
SOCIAL
🎙 - Twitter: https://twitter.com/antonvputra
📨 - Email: me@antonputra.com

#Kubernetes #EFS #NFS #AWS

#kubernetes #aws

What is GEEK

Buddha Community

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

AWS Fargate for Amazon Elastic Kubernetes Service | Caylent

On-demand cloud computing brings new ways to ensure scalability and efficiency. Rather than pre-allocating and managing certain server resources or having to go through the usual process of setting up a cloud cluster, apps and microservices can now rely on on-demand serverless computing blocks designed to be efficient and highly optimized.

Amazon Elastic Kubernetes Service (EKS) already makes running Kubernetes on AWS very easy. Support for AWS Fargate, which introduces the on-demand serverless computing element to the environment, makes deploying Kubernetes pods even easier and more efficient. AWS Fargate offers a wide range of features that make managing clusters and pods intuitive.

Utilizing Fargate
As with many other AWS services, using Fargate to manage Kubernetes clusters is very easy to do. To integrate Fargate and run a cluster on top of it, you only need to add the command –fargate to the end of your eksctl command.

EKS automatically configures the cluster to run on Fargate. It creates a pod execution role so that pod creation and management can be automated in an on-demand environment. It also patches coredns so the cluster can run smoothly on Fargate.

A Fargate profile is automatically created by the command. You can choose to customize the profile later or configure namespaces yourself, but the default profile is suitable for a wide range of applications already, requiring no human input other than a namespace for the cluster.

There are some prerequisites to keep in mind though. For starters, Fargate requires eksctl version 0.20.0 or later. Fargate also comes with some limitations, starting with support for only a handful of regions. For example, Fargate doesn’t support stateful apps, DaemonSets or privileged containers at the moment. Check out this link for Fargate limitations for your consideration.

Support for conventional load balancing is also limited, which is why ALB Ingress Controller is recommended. At the time of this writing, Classic Load Balancers and Network Load Balancers are not supported yet.

However, you can still be very meticulous in how you manage your clusters, including using different clusters to separate trusted and untrusted workloads.

Everything else is straightforward. Once the cluster is created, you can begin specifying pod execution roles for Fargate. You have the ability to use IAM console to create a role and assign it to a Fargate cluster. Or you can also create IAM roles and Fargate profiles via Terraform.

#aws #blog #amazon eks #aws fargate #aws management console #aws services #kubernetes #kubernetes clusters #kubernetes deployment #kubernetes pods

Kubernetes Persistent Volumes NFS(AWS|EKS|EFS Storage Class|EFS Provisioner|ReadWriteMany)

Kubernetes Persistent Volumes NFS tutorial will cover creating and attaching NFS volumes to Kubernetes pods. We are going to create a network file system in AWS which is called EFS. We will create a Kubernetes NFS provisioner and provide an EFS IP address. Also, we will create a storage class based on that provisioner. Finally, we will create a persistent volume claim with the ReadWriteMany attribute and mount it to separate applications to test shared access to that volume.

Did I help you out?
☕ Buy Me a Coffe: https://www.buymeacoffee.com/antonputra
🔴 Add me on LinkedIn: https://www.linkedin.com/in/anton-putra

=========
⏱️TIMESTAMPS⏱️
0:00 Intro
2:15 Create EFS File System
6:04 Create Kubernetes NFS Provisioner
12:35 Create EFS Storage Class EKS
18:44 Create NFS Persistent Volume Claim
22:25 Share ReadWriteMany Volume with 2 Apps

=========
Source Code
📚 - Instructions: https://antonputra.com
🖥️ - GitHub: https://github.com/antonputra/tutorials/tree/main/lessons/041

=========
SOCIAL
🎙 - Twitter: https://twitter.com/antonvputra
📨 - Email: me@antonputra.com

#Kubernetes #EFS #NFS #AWS

#kubernetes #aws

Working With Persistent Volumes in Kubernetes

Introduction

The main reason behind containerization is to allow microservices to run in a stateless way. A container will receive provisioned cloud resources, perform its tasks, and then be destroyed as soon as the process is over. There are no traces of that container or tied up cloud resources to worry about. This was what has made containerization so popular in the first place.

Running microservices as stateless instances, however, is not always as easy as it seems. As more applications get refactored and more microservices rely on containers for efficiency, sticking with the stateless concept becomes harder and harder. Stateless containers don’t always have the ability to meet complex requirements.

Here’s a simple truth: truly stateless applications, those that require no data to be stored over a long period of time, are unicorns; they are incredibly difficult to find in the wild, if not impossible. This is where persistent volumes, or stateful storage, come in handy. It bridges the gap between ideal containerization and the requirements of apps and services.

Kubernetes Persistent Volume

Before we go further into how persistent volumes can be utilized, we need to take a closer look at persistent volume in Kubernetes. Kubernetes has always managed its storage resources in a peculiar way. It provisions, configures, and attaches storage blocks using a specific process or primitive; they must be executed for the volumes to be usable.

Provisioning is the simplest part of the equation. This is the part where Persistent Volumes are created. You have the option to provision volumes statically or dynamically—we will get to this in a bit. Configuration of volumes is handled as Storage Class. Storage Class contains details on the volumes they are associated with.

To complete the process, the volumes need to be attached to pods. Persistent Volume Claims are issued by pods whenever they need to use the storage blocks. A Persistent Volume Claim details the amount of storage required as well as other requirements based on the pods’ operations. Volumes can be attached and detached without being destroyed.

Persistent Volume is slightly different from Ephemeral Volume in one way: the latter exists only for as long as the pods exist. Unlike Persistent Volume, Ephemeral Volume is created during the pod creation process and gets destroyed when the pod is destroyed. It is handy for storing temporary data or for supporting certain operations such as data visualization.

#kubernetes #containers #storage #containers and containerization #persistent storage #persistent volume

How to Use AWS IAM Role on AWS EKS PODs

A native-AWS way to attach an IAM role into the Kubernetes POD, without third-party software, reducing latency and improving your EKS security.

How It Works

It’s possible to attach an IAM role in a Kubernetes POD without using third-party software, such as kube2iam and kiam. This is thanks to the integration between AWS IAM and Kubernetes ServiceAccount, following the approach of IAM Roles for Service Accounts (IRSA).

---

Benefits

There are quite a few benefits of using IRSA with Kubernetes PODs.

• Granular restriction (per cluster, per namespace, etc.).
• It’s also possible to not use it.
• More flexible than the other tools.
• One less point of failure (maybe a few less).
• Lesser resource consumption.
• More pods per node.
• Latency may reduce by ~50ms.
• Especially for the first request.
• Prevent issues with caching the credentials.
• This software takes a few minutes to update its cache.
• Better auditing.
• Instead of checking the logs of kube2iam/kiam pods, you can check AWS CloudTrails.
• Easier to set up.
• AWS provides full support.

---

Pre-requirements

There are a few pre-requirements that you’ll need to attempt in order to use the IAM role in a POD.

• An IAM OpenID Connect provider pointing to the AWS EKS OpenID Connect provider URL.
• AWS EKS cluster 1.13 or above.
• A trust relationship between your IAM Role and the OpenID Provider.

#cloud #tutorial #aws #kubernetes #cloud security #k8s #eks #aws security #kubernetes security #aws iam