In this article we are going to discuss how to configure Azure blob storage as sftp server. Knowing the fact that Azure blob is used as a massively scalable and secure object storage for cloud-native workloads. To check more details about the Azure Blob kindly check this URL.

Following are the steps we need to follow in order to configure Azure blob storage as sftp server.

1.Create storage account:First of all you need to have the storage account. If not you can create the new storage account. To create the storage account click on the “Microsoft Azure” on the top left corner once you logged into Azure portal.  Then click on the “Create a resource” (with + sign) link.

2. In the next window type “storage account” and select the Storage account option to go ahead.

3.  In the next window click on the “Create” button selecting “Storage account” option as below:

4. In the next window select “Subscription” & “Resource group” as per your azure account. Then give proper name to your storage account. In my demo I have used “mylraccount” as below in the screenshot. Also select proper region as per your requirement under region option.

5. In the Advanced tab tick mark the option “Enable hierarchical namespace” and also tick mark the “Enable SFTP” and “Enable network file system v3” Option. This selection necessary to configure Azure blob storage as sftp server.

mylraccount.<CONTAINER_NAME>.demouser@mylraccount.blob.core.windows.net

try connect with sftp client :

(base) ➜  ~ sftp mylraccount.mydata.demouser@mylraccount.blob.core.windows.net
The authenticity of host 'mylraccount.blob.core.windows.net (20.209.0.229)' can't be established.
ECDSA key fingerprint is SHA256:ixDeCdmQOB9ROqdJiVdXyFVsRqLmJJUb2M4shrWj8gI.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:22: mylrstorageacct1121.blob.core.windows.net
    ~/.ssh/known_hosts:23: mylrstorage.blob.core.windows.net
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mylraccount.blob.core.windows.net' (ECDSA) to the list of known hosts.
mylraccount.mydata.demouser@mylraccount.blob.core.windows.net's password: 
Connected to mylraccount.blob.core.windows.net.
sftp> 

when prompted select yes for “Are you sure you want to continue connecting” and enter the password captured in the step 14.  For testing i have just upload sample file named “untitled.txt“.

Connected to mylraccount.blob.core.windows.net.
sftp> put untitled.txt
Uploading untitled.txt to /untitled.txt
untitled.txt                                                                           100%    0     0.0KB/s   00:00    
sftp> 

You can see that uploaded “untitled.txt” in our mydata container.

So this how we can configure Azure blob storage as sftp server.

The post How to configure Azure blob storage as sftp server appeared first on UX Techno.

In this post we are going to learn how to use scatter plot using Plotly library in Python.

The data points  we are going to fetch from the API. Here the API link is “https://covid19-mohfw.herokuapp.com/“. This API  is the public API for COVID-19 cases in India, updated directly from MOHFW website. So using this data we are going to plot state wise data for deaths and cases.

In this post we are going to plot bubble chart,  which helps to displays multiple circles (bubbles) in a 2D plot as same in scatter plot.

import pandas as pd
import plotly.express as px
import requests

response = requests.get("https://covid19-mohfw.herokuapp.com/")

data=response.json()
df=pd.json_normalize(data['states'])
fig = px.scatter(df, x="deaths",y="cases",size="deaths", color="state",log_x=True, size_max=60)

fig.show()
print(df)

Here is the Output of the above code:

Please check this link for the Jupyter notebook.

The post How to draw scatter plot using Plotly library in Python. appeared first on UX Techno.

About FastAPI:

FastAPI is a framework written in Python 3. FastAPI also gives you the flexibility to provide you Swagger UI documentation which helps you if you are working in a multimember team or to give it a front-end team.  Also, you don’t need a tool like Postman to test your API. It’s really easy to code your API if you know a little bit about Python. To check more details on the same please check this link

Pre-requisite for FastAPI

• Python 3.6+
• FastAPI module (Can be installed using pip3)
• Uvicorn (webserver hosting the api in your system. This also can be istalled using pip3)
• Editor (vs Code)

Steps to Create simple API using FastAPI in Python

1. Install Python 3.6+. Please follow this link to complete this. Make sure you install versions greater than 3.6.
2. Create a Virtual environment using the below command:

python3 -m venv myfastapienv

The above command creates the subdirectory called mysfastapinv which is the name we gave to our virtual environment.

Activate the virtual environment.

C:\FastAPI> .\myfastapienv\Scripts\activate

(myfastapienv) C:\FastAPI>

Now you will see that our virtual environment is activated as shown above.

Install fastapi and uvicorn.

1. Install the FastAPI and Uvicorn which will be the web server for the FastAPI using the below command:

(myfastapienv) C:\FastAPI>pip3 install fastapi uvicorn

2. Now we will create the sample python script with .py extension. in the “/myfastapienv/Scripts” location called main.py as below:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def baseurl():
    return {"Hello from Base PATH"}

@app.get("/hello")
def baseurl():
    return {"Hello from /hello PATH"}

@app.get('/user/{name}')
def show(name: str):
    return {f"Hello from the /user PATH {name}"}

Following is a description of the code:

Line 1: At line 1 we imported FastAPI library

Line 3: At line 3 we created one instance of the FastAPI class called “app”. This name can be anything.

Line 5-7: Between the line 5-7 we define the PATH and respective function to be called which simply returns “Hello from Base PATH” message.  This request is of the type “GET”. This is the default PATH of our API.

Line 9-11: Between the line 9-11 we define the PATH and respective function to be called which simply returns“Hello from /hello PATH” message.  This request is of the type “GET”.

Line 13-15: Between the line 13-15 we define the PATH and respective function to be called which simply returns f“Hello from the /user PATH {name}” message.  This request is of the type “GET”. Here we passing the name variable and printing the Hello message to that user.

Start the uvicorn webserver:

Once you save the file at the command prompt use the below command to start the uvincorn webserver. Here we have used reload parameter so that we don’t have to restart the web server every time we save the main.py file.

(myfastapienv) C:\FastAPI\myfastapienv\Scripts>uvicorn main:app --reload

If you look at line 1 we are using main parameter since we are using “main.py” in our demo and “app” parameter since its the name of the instance we created in the main.py file(check line 3 from the code)

Log snippet:

(myfastapienv) C:\FastAPI\myfastapienv\Scripts>uvicorn main:app --reload
←[32mINFO←[0m:     Will watch for changes in these directories: ['C:\\FastAPI\\myfastapienv\\Scripts']
←[32mINFO←[0m:     Uvicorn running on ←[1mhttp://127.0.0.1:8000←[0m (Press CTRL+C to quit)
←[32mINFO←[0m:     Started reloader process [←[36m←[1m3396←[0m] using ←[36m←[1mstatreload←[0m
←[32mINFO←[0m:     Started server process [←[36m1584←[0m]
←[32mINFO←[0m:     Waiting for application startup.
←[32mINFO←[0m:     Application startup complete.

If you check the above logs our API URL is “http://localhost:8000”

Now let’s just access the following URL to check if everything is working is fine or not.

Base URL 1: http://localhost:8000/

hello URL 2: http://localhost:8000/hello

user URL 3: http://localhost:8000/user/Manmohan

Please note here parameter Manmohan can be replaced with any name. Our API will print out Hello message accordingly.

OR http://localhost:8000/user/Linuxroutes

Swagger UI: 

Another nice feature of FastAPI is Swagger UI. This means FastAPI gives us nice documentation about the API created automatically. To access the Swagger UI simply append /docs to your main URL of the API. In our case it is “http://localhost:8000/docs”

If you look at above screenshot it mentioned about three PATHs which are of the type GET. Also if you click down arrow given at right side of each PATH you will come to know more details such as mandatory field and field type etc. as below:

In case you want to pass some parameters to the API simply click on “Try out” button. and enter the parameter value as below:

Once you click on Execute button you will get the response from the API as below:

Because of this you don’t need another tool such as Postman to test your API. There is also another type of API documentation available with FastAPI which is called “redoc”. To access this documentation simply add the keyword “redoc” to your base API URL. In our case its “http://localhost:8000/redoc” . This looks as below:

So this is all about “Create simple API using FastAPI in Python”.

The post How to Create simple API using FastAPI in Python appeared first on UX Techno.

In this article we will discuss about, how to drain node in Kubernetes cluster. For maintenance activity such as patching etc.  requires downtime. In order to carry out such activities without impacting applications running within cluster, we need to follow some step by step command. We will discuss those commands in this article for impact less maintenance.

How to drain node in Kubernetes cluster?

Pre-requisite:

We have got Kubernetes cluster with one master node and two worker node as below:

$ kubectl get node
NAME          STATUS   ROLES    AGE    VERSION
k8s-control   Ready    master   167m   v1.18.5
k8s-worker1   Ready    <none>   166m   v1.18.5
k8s-worker2   Ready    <none>   166m   v1.18.5
$ 

Now lets run one pod and one deployment with following YAML definition as below for the testing purpose:

Pod Definition:

$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
 containers:
 - name: nginx
   image: nginx
   ports:
   - containerPort: 80

Deployment definition:

$ cat deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: my-deployment
spec:
 replicas: 2
 selector:
    matchLabels:
     app: my-deployment
 template:
   metadata:
    labels:
      app: my-deployment
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80

Now lets run both the definition file for creating the objects:

$ kubectl create -f pod.yaml
pod/my-pod created
$ kubectl create -f deploy.yaml
deployment.apps/my-deployment created
$

Cross verify the nodes on which Pod and the deployment Pods are running using below command:

$ kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
my-deployment-655f58b4cb-2sn4r   1/1     Running   0          25s     192.168.194.70   k8s-worker1   <none>           <none>
my-deployment-655f58b4cb-t4s7t   1/1     Running   0          25s     192.168.126.6    k8s-worker2   <none>           <none>
my-pod                           1/1     Running   0          5m13s   192.168.126.5    k8s-worker2   <none>           <none>
$

You can also see from the above output that, single Pod is running on the worker node “k8s-worker2” and the deployment pods are running on the both the nodes of Kubernetes cluster.

Draining the node?

Now lets drain the node “k8s-worker2” since its running Pod and the deployment Pods also.

$ kubectl drain k8s-worker2 --ignore-daemonsets --force
node/k8s-worker2 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-system/calico-node-svhvv, kube-system/kube-proxy-5nk2w; deleting Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet: default/my-pod
evicting pod default/my-deployment-655f58b4cb-hkdfh
evicting pod default/my-pod
pod/my-pod evicted
pod/my-deployment-655f58b4cb-hkdfh evicted
node/k8s-worker2 evicted
$

Note:

Make sure you use the option “–ignore-daemonsets” and “–force” in case you have standalone Pod and deployment running within your Kubernetes cluster other wise system wont allow you to drain the node and it throws following error:

$ kubectl drain k8s-worker2
node/k8s-worker2 cordoned
error: unable to drain node "k8s-worker2", aborting command...

There are pending nodes to be drained:
 k8s-worker2
cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): kube-system/calico-node-svhvv, kube-system/kube-proxy-5nk2w
cannot delete Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to override): default/my-pod
$

Once you drain the node successfully check the status of the node using below command:

$ kubectl get node
NAME          STATUS                     ROLES    AGE    VERSION
k8s-control   Ready                      master   172m   v1.18.5
k8s-worker1   Ready                      <none>   171m   v1.18.5
k8s-worker2   Ready,SchedulingDisabled   <none>   171m   v1.18.5
$

In the above output you can see that the node “k8s-worker2” has been marked as disabled for Scheduling the resource on it.  Now lets check the status of our Pod and Deployment Pods after draining the node.

$ kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE    IP               NODE          NOMINATED NODE   READINESS GATES
my-deployment-655f58b4cb-2sn4r   1/1     Running   0          116s   192.168.194.70   k8s-worker1   <none>           <none>
my-deployment-655f58b4cb-gtjt4   1/1     Running   0          20s    192.168.194.71   k8s-worker1   <none>           <none>
$

From the above output its cleared that, the standalone Pod “my-pod” being deleted due to Drain activity, however Pod that is being run using deployment got killed and rescheduled on the other node which is “k8s-worker1”.

Joining the maintenance node back again to the Kubernetes cluster: 

Now lets assume that, our maintenance activity on the node “k8s-worker2” is completed and we want to join the node to our Kubernetes cluster. Then we need to uncordon the node as below:

$ kubectl uncordon k8s-worker2
node/k8s-worker2 uncordoned
$

Now if you check the status of the node it will show Ready status and that to without “SchedulingDisabled” status as below:

$ kubectl get node
NAME          STATUS   ROLES    AGE    VERSION
k8s-control   Ready    master   174m   v1.18.5
k8s-worker1   Ready    <none>   174m   v1.18.5
k8s-worker2   Ready    <none>   174m   v1.18.5
$

And also if you check the status of the deployment Pods its remains unchanged.

$ kubectl get pods -o wide
NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE          NOMINATED NODE   READINESS GATES
my-deployment-655f58b4cb-2sn4r   1/1     Running   0          3m37s   192.168.194.70   k8s-worker1   <none>           <none>
my-deployment-655f58b4cb-gtjt4   1/1     Running   0          2m1s    192.168.194.71   k8s-worker1   <none>           <none>
$

This states that, even if you join the maintenance node again back to Kubernetes cluster the earlier running Pods keeps running on the same node.

So this is all about question “How to drain node in Kubernetes?” for the maintenance activity.

In case you want to go through other Kubernetes articles follow this link.

The post How to drain node in Kubernetes cluster for maintenance activity. appeared first on UX Techno.

In this article we will be discussing more about Kubernetes namespaces. Basically we will try to understand what is Kubernetes namespace, how to create it and use it in real scenario.

What is Kubernetes namespaces?

Kubernetes namespaces is a virtual cluster being created within the actual Kubernetes cluster. This will bring separation between the different Kubernetes objects such as Pods, deployments and service etc. This will comes handy in order to separate your cluster environment wise or among the different teams.

How to create Kubernetes namespaces:

Basically there are two methods by which you can create namespaces in Kubernetes:

• By using the YAML based definitions:

In this method we will defining the namespaces in the YAML file and creating the namespace using the “kubectl create” command as below:

Create the sample YAML file with following contents:

$ cat ns.yaml
apiVersion: v1
kind: Namespace
metadata:
name: test

Now create the namespace object using below command:

$ kubectl create -f ns.yaml
namespace/test created
$

Now list down all the namespaces to cross-verify whether “test” namespace created or not:

$ kubectl get ns
NAME              STATUS   AGE
default           Active   23m
kube-node-lease   Active   23m
kube-public       Active   23m
kube-system       Active   23m
mobile-gateway    Active   23m
oasis             Active   23m
test              Active   19s
$

• Other method will be creating namespace using command line.

Here in this method we will be creating the namespace directly using kubectl create command as below:

$ kubectl create namespace my-namespace
namespace/my-namespace created
$ kubectl get ns
NAME              STATUS   AGE
default           Active   38m
kube-node-lease   Active   38m
kube-public       Active   38m
kube-system       Active   38m
mobile-gateway    Active   38m
my-namespace      Active   57s
oasis             Active   38m
test              Active   15m
$

How to create the objects within the namespaces

In this demo we will create sample Pod within the “test” namespace that we have created in earlier step. For this create a Pod definition file as below which will define the namespace within which it has to be created.

$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: podintest-ns
namespace: test
spec:
containers:
- name: mynginx
image: nginx
$

Now create the Pod using kubectl create command as below:

$ kubectl create -f pod.yaml
pod/podintest-ns created
$

Now in order to list down the Pod status you need to specify the namespace by adding option with “–namespace=test”.

$ kubectl get pods --namespace=test
NAME           READY   STATUS    RESTARTS   AGE
podintest-ns   1/1     Running   0          11s
$

Note: In case you dont specify the namespace option while listing out the objects, Kubernetes will show the objects from the default namespace. So you need to make sure that you are specifying the namespaces while listing out the Kubernetes objects.

Trick!

In case you are not sure about the namespace within which object is created simply use following command which will list down objects(Pods) within all the namespace from the cluster.

kubectl get pods --all-namespaces

Delete namespace

Please note that here while deleting the namespace it will also delete the objects within the namespace. So be cautious while deleting the namespace. In order to delete the namespace use below command:

$ kubectl delete ns test
namespace "test" deleted
$ kubectl delete ns my-namespace
namespace "my-namespace" deleted
$

So this is how we can use namespace in Kubernetes cluster in order to separating the objects within your Kubernetes cluster.

The post Everything you need to know about Kubernetes namespaces. appeared first on UX Techno.

This article will guide you about how to create HostPath persistent volume in Kubernetes.

You might be knowing that data in the Pod exists till the life time of the Pod. If the Pod dies all your data that belongs to the Pod is also goes away along with Pod. So if you want to persist your data beyond the life cycle of the Pod then you must have some thing called as a Persistent volume in Kubernetes.

So lets study how to How to create HostPath persistent volume which is very easy to experiment. Also to gain knowledge about the fundamentals about the Persistent volume.

There are following types of Persistent volume types available to use within kubernetes by different vendors.

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• CSI
• FC (Fibre Channel)
• FlexVolume
• Flocker
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• HostPath (Single node testing only — local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
• Portworx Volumes
• ScaleIO Volumes
• StorageOS

As you can see for the HostPath it should be used only for the testing purpose. Also it does not support multi-node cluster. In case you want to explore more about the Persistent volumes you may follow this link.

The Basic process for Persistent volumes is as follows:

1. K8s admin create the persistence volume in cluster.
2. User will claim it using Persistent volume claim once they claimed it status becomes “Bound”.
3. Then Pod use that volume for storing out the data which will persist across the life-cycle of Pod.

Enough for the theory Part Lets jump the Technical steps towards it:

• Create the persistent volume

In this step we are using following manifest yaml file to achieve the same.

# cat hostpath-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/tmp/kube"

As shown in the above definition file it is for the size 1GB. Path is “/tmp/kube”. Lets create the PV as below:

# kubectl create -f hostpath-pv.yaml
persistentvolume/pv-hostpath created

Recheck the PV and persistent volume claim using below command:

# kubectl get pv,pvc -o wide
NAME                           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE   VOLUMEMODE
persistentvolume/pv-hostpath   1Gi        RWO            Retain           Available           manual                  6s    Filesystem

As you can see the PV is created having status as Available and since we haven’t specified the reclaim policy default is applied which is “Retain” meaning that the even if the pvc (Persistent volume claim) gets deleted the PV and data wont get deleted automatically. We will test it out that also in a bit.

• Create the Persistent volume claim

In order to use the PV we need to create the Persistent volume claim or pvc to use it.  Here is the manifest yaml file for the same.

# cat pvc-hostpath.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-hostpath
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi

Kindly note in the above definition that the claim is only for the 100mb(>= size of PV) also the Access mode is “ReadWriteOnce” which is same as that of PV. Hence we can able to create the PVC as below:

# kubectl create -f pvc-hostpath.yaml
persistentvolumeclaim/pvc-hostpath created

Check the status of pv and pvc.

# kubectl get pv,pvc -o wide
NAME                           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE   VOLUMEMODE
persistentvolume/pv-hostpath   1Gi        RWO            Retain           Bound    default/pvc-hostpath   manual                  20s   Filesystem

NAME                                 STATUS   VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
persistentvolumeclaim/pvc-hostpath   Bound    pv-hostpath   1Gi        RWO            manual         4s    Filesystem

You will see that the status of the pv becomes Bound from Available which was earlier.

• Create the Pod to utilize this PV as a mount point inside it.

# cat busybox-pv-hostpath.yaml
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  volumes:
  - name: host-volume
    persistentVolumeClaim:
      claimName: pvc-hostpath
  containers:
  - image: busybox
    name: busybox
    command: ["/bin/sh"]
    args: ["-c", "sleep 600"]
    volumeMounts:
    - name: host-volume
      mountPath: /tmp/mydata

As describe in the Pod definition file it will create the mount point /tmp/mydata inside the Pod. Lets create the Pod using above definition file.

# kubectl create -f busybox-pv-hostpath.yaml
pod/busybox created

Check the status and inspect the Pod:

# kubectl get all -o wide
NAME          READY   STATUS    RESTARTS   AGE    IP             NODE        NOMINATED NODE   READINESS GATES
pod/busybox   1/1     Running   0          2m4s   10.244.1.114   kworker01   <none>           <none>

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE   SELECTOR
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   35d   <none>

# kubectl describe pod busybox
Name:         busybox
Namespace:    default
Priority:     0
Node:         kworker01/10.253.121.32
Start Time:   Mon, 06 Jul 2020 02:43:16 -0400
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           10.244.1.114
IPs:
  IP:  10.244.1.114
Containers:
  busybox:
    Container ID:  docker://6d1cfa9b6440efe2770244d1edc6a78c0dd7649bbf905121e70a013ad3b1dd1e
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:9ddee63a712cea977267342e8750ecbc60d3aab25f04ceacfa795e6fce341793
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
    Args:
      -c
      sleep 600
    State:          Running
      Started:      Mon, 06 Jul 2020 02:43:25 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /tmp/mydata from host-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-49xz2 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  host-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  pvc-hostpath
    ReadOnly:   false
  default-token-49xz2:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-49xz2
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age        From                Message
  ----    ------     ----       ----                -------
  Normal  Scheduled  <unknown>  default-scheduler   Successfully assigned default/busybox to kworker01
  Normal  Pulling    64s        kubelet, kworker01  Pulling image "busybox"
  Normal  Pulled     58s        kubelet, kworker01  Successfully pulled image "busybox"
  Normal  Created    58s        kubelet, kworker01  Created container busybox
  Normal  Started    57s        kubelet, kworker01  Started container busybox

In the describe output you can see that, /tmp/mydata volume got created using host-volume from the claim pvc-hostpath. Also the Pod is scheduled/create on the node “kworker01”.

Lets login inside the Pod to create the sample file. In order to demonstrate the life cycle of the data even if the Pod dies.

# kubectl exec -it busybox -- sh
/ # hostname
busybox
/ # cd /tmp/
/tmp # ls
mydata
/tmp # cd mydata/
/tmp/mydata # echo "hello from K8S" > Hello.txt
/tmp/mydata # ls -ltr
total 4
-rw-r--r--    1 root     root            15 Jul  6 06:46 Hello.txt
/tmp/mydata #

In the above demo we have created file “Hello.txt” inside /tmp/mydata. Now lets delete the Pod.

# kubectl delete pod busybox
pod "busybox" deleted
root@vbhost:~/kubernetes/yamls# kubectl get all
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   35d

Pod got deleted successfully lets login to the node “kworker01” where Pod got scheduled earlier to check if the data still persist after the deletion of the Pod.

sh-4.2# hostname
kworker01
sh-4.2# cd /tmp
sh-4.2# ls
kube
sh-4.2# cd kube/
sh-4.2# ls
Hello.txt
sh-4.2# cat Hello.txt
hello from K8S
sh-4.2# exit

You can see that our file “Hello.txt” still exists on the Node even the Pod dies.

So this is all about “How to create HostPath persistent volume” in Kubernetes.

The post How to create HostPath persistent volume in Kubernetes appeared first on UX Techno.

In this article we are going to learn  how to configure ingress controller in kubernetes so that we could run multi domain or subdomain application within same kubernetes cluster.

In this demo we are going to run application with domain “nginx.example.com” and other two subdomain called

tea.myshop.com and coffee.myshop.com in kubernetes using Nginx ingress controller. Please note that, these domains and subdomains are local domains.

To show case this demo about “How to configure ingress controller in kubernetes” I am using lxc containers install on Ubuntu(Bare-metal installation). Basically I have four containers/vms running on the lxc host as below:

root@vbhost:~# lxc list
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+
|   NAME    |  STATE  |          IPV4          |                     IPV6                      |    TYPE    | SNAPSHOTS |
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+
| haproxy   | RUNNING | 10.253.121.146 (eth0)  | fd42:38af:bc0d:704d:216:3eff:fefa:cb4c (eth0) | PERSISTENT | 0         |
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+
| kmaster   | RUNNING | 172.17.0.1 (docker0)   | fd42:38af:bc0d:704d:216:3eff:fe31:7a49 (eth0) | PERSISTENT | 0         |
|           |         | 10.253.121.39 (eth0)   |                                               |            |           |
|           |         | 10.244.0.0 (flannel.1) |                                               |            |           |
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+
| kworker01 | RUNNING | 172.17.0.1 (docker0)   | fd42:38af:bc0d:704d:216:3eff:fed4:8226 (eth0) | PERSISTENT | 0         |
|           |         | 10.253.121.32 (eth0)   |                                               |            |           |
|           |         | 10.244.1.1 (cni0)      |                                               |            |           |
|           |         | 10.244.1.0 (flannel.1) |                                               |            |           |
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+
| kworker02 | RUNNING | 172.17.0.1 (docker0)   | fd42:38af:bc0d:704d:216:3eff:fe9f:82c0 (eth0) | PERSISTENT | 0         |
|           |         | 10.253.121.89 (eth0)   |                                               |            |           |
|           |         | 10.244.2.1 (cni0)      |                                               |            |           |
|           |         | 10.244.2.0 (flannel.1) |                                               |            |           |
+-----------+---------+------------------------+-----------------------------------------------+------------+-----------+

• So all these containers are running centos. Three of them are being used for kubernetes cluster. One will be using for haproxy which we will be utilizing as a loadbalancer to load balance the request to one of the two kubernetes worker node.

To learn more about lxc containers follow this link.

Steps:

• Deploy kubernetes cluster:

Once you deployed three lxc containers configure one of them as kubernetes master and other two as kubernetes worker node. To cut short the configuration journey  you can follow this link.

• Deploy ha-proxy container with centos operating system:

We will be deploying one more lxc container with centos and will be configuring haproxy as per below steps:

• login to lxc container

root@vbhost:~# lxc exec haproxy bash
[root@haproxy ~]#

Now install the haproxy package in the container

# yum install haproxy

Once you have installed haproxy we need change the configuration so that it will load balance the traffic between the kubernetes worker node. Open the /etc/haproxy/haproxy.cfg file and replace it with below contents:

[root@haproxy ~]# cat /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# Example configuration for a possible web application.  See the
# full configuration options online.
#
#   http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2

    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend http_front
  bind *:80
  stats uri /haproxy?stats
  default_backend http_back

backend http_back
  balance roundrobin
  server kube 10.253.121.32:80
  server kube 10.253.121.89:80
[root@haproxy ~]#

Make sure you change the bottom two ip address with ip address of the kubernetes worker nodes so that it could be load balanced. Here are the ip adress of my worker node which we have entered in the above haproxy configuration file. Also we are using http port 80 for our configuration.

# kubectl get nodes -o wide
NAME        STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION       CONTAINER-RUNTIME
kmaster     Ready    master   31d   v1.17.1   10.253.121.39   <none>        CentOS Linux 7 (Core)   4.15.0-106-generic   docker://19.3.5
kworker01   Ready    <none>   31d   v1.17.1   10.253.121.32   <none>        CentOS Linux 7 (Core)   4.15.0-106-generic   docker://19.3.5
kworker02   Ready    <none>   31d   v1.17.1   10.253.121.89   <none>        CentOS Linux 7 (Core)   4.15.0-106-generic   docker://19.3.5
#

Now restart and enable the haproxy service.

# systemctl enable haproxy
# systemctl restart haproxy

We are done with haproxy configuration. Now logout from it.

• Install the Nginx-controller on kubernetes master node:

Clone the git repo  and change directory to “kubernetes-ingress/deployments/”

# git clone https://github.com/nginxinc/kubernetes-ingress.git
# cd kubernetes-ingress/deployments/

Create the namespace and service account.

# kubectl apply -f common/ns-and-sa.yaml

Apply the role and cluster role binding

# kubectl apply -f rbac/rbac.yaml

Make the secret

# kubectl apply -f common/default-server-secret.yaml

apply the configmap required.

# kubectl apply -f common/nginx-config.yaml

Now deploy the Ingress controller as daemon-set

# kubectl apply -f daemon-set/nginx-ingress.yaml

Now if you check the namespace and the resources within “nginx-ingress” namespace you will find similar resources being created.

# kubectl get ns
NAME              STATUS   AGE
cattle-system     Active   29d
default           Active   31d
efk               Active   29d
kube-node-lease   Active   31d
kube-public       Active   31d
kube-system       Active   31d
nginx-ingress     Active   10s

# kubectl get all -n nginx-ingress
NAME                      READY   STATUS              RESTARTS   AGE
pod/nginx-ingress-2rq6s   0/1     ContainerCreating   0          14s
pod/nginx-ingress-65vnd   0/1     ContainerCreating   0          14s

NAME                           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/nginx-ingress   2         2         0       2            0           <none>          14s

Once they are ready we are going to deploy services.

• Deploy the Nginx service with NodePort type listening on port 80 which will run sample Nginx web-server with its default index.html file. Here is manifest file I am using for it.

# cat nginx-deploy-main.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx-deploy-main
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx-main
  template:
    metadata:
      labels:
        run: nginx-main
    spec:
      containers:
      - image: nginx
        name: nginx


---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy-main
spec:
  type: NodePort
  selector:
    run: nginx-main
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80

Deploy the Nginx service

# kubectl create -f nginx-deploy-main.yaml
deployment.apps/nginx-deploy-main created
service/nginx-deploy-main created

• Deploy the tea service 

Now lets deploy the another service which will be of the type NodePort with port 80.  For this service I am using my own created docker image called “manmohanmirkar/mytea_image” which will simply display the message “This is Tea Shop” in the browser. This service will be get called once you  try to access url “tea.myshop.com” . Sample manifest file is as below:

# cat tea.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: tea
  name: tea-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: manmohanmirkar/mytea_image:latest

---
apiVersion: v1
kind: Service
metadata:
  name: tea-deploy
spec:
  type: NodePort
  selector:
    app: tea
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80

Apply the tea service:

# kubectl create -f tea.yml
deployment.apps/tea-deploy created
service/tea-deploy created

• Configure the coffee service

Deploy one more service which will be of the type NodePort with port 80.  For this service I am using my own created docker image called “manmohanmirkar/mycoffee_image” which will simply display the message “This is Coffee Shop” in the browser. This service will be get called once you  try to access url “coffee.myshop.com” . Sample manifest file is as below:

# cat coffe.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: coffee
  name: coffee-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: manmohanmirkar/mycoffee_image:latest
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-deploy
spec:
  type: NodePort
  selector:
    app: coffee
  ports:
      # By default and for convenience, the `targetPort` is set to the same value as the `port` field.
    - port: 80

Now lets apply the coffee service and deployment.

# kubectl create -f coffe.yml
deployment.apps/coffee-deploy created
service/coffee-deploy created

• Deploy the Ingress resource

This is the main configuration in this article which will configure the Ingress resource. This Ingress resource will be performing the task of routing the request to respective service based on the URL. Let have look at the manifest file for the same:

# cat cafe-ingress.yml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress-resource
spec:
  rules:
  - host: nginx.example.com
    http:
      paths:
      - backend:
          serviceName: nginx-deploy-main
          servicePort: 80
  - host: tea.myshop.com
    http:
      paths:
      - backend:
          serviceName: tea-deploy
          servicePort: 80
  - host: coffee.myshop.com
    http:
      paths:
      - backend:
          serviceName: coffee-deploy
          servicePort: 80

Basically in the above file will deploy the resource type Ingress. It has got three host based rules configured for each service. So if the host url is “nginx.example.com” then it has backend with service Name “nginx-deploy-main”. Basically it means that whenever the request with URL “nginx.example.com” made it will be get forwarded to the service “nginx-deploy-main”.

In the similar way we have two more hosts “tea.myshop.com” and “coffee.myshop.com” with backed configured as “tea-deploy” and “coffee-deploy”. This also means that whenever the request made with URL “tea.myshop.com” to the haproxy serrver it will forwarded to the service “tea-deploy”. Also in the similar way if the request with URL “coffee.myshop.com” it will be automatically get forwarded to the service “coffee-deploy” which we have already deployed.

Now lets deploy the ingress resource:

# kubectl create -f cafe-ingress.yml
ingress.networking.k8s.io/my-ingress-resource created

Crosscheck the ingress resource with following commands:

# kubectl describe ing
Name:             my-ingress-resource
Namespace:        default
Address:
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
  Host               Path  Backends
  ----               ----  --------
  nginx.example.com
                        nginx-deploy-main:80 (10.244.2.82:80)
  tea.myshop.com
                        tea-deploy:80 (10.244.1.94:80,10.244.2.83:80)
  coffee.myshop.com
                        coffee-deploy:80 (10.244.1.95:80,10.244.2.84:80)
Annotations:         <none>
Events:
  Type    Reason          Age   From                      Message
  ----    ------          ----  ----                      -------
  Normal  AddedOrUpdated  31s   nginx-ingress-controller  Configuration for default/my-ingress-resource was added or updated
  Normal  AddedOrUpdated  31s   nginx-ingress-controller  Configuration for default/my-ingress-resource was added or updated

You can able to see from the output that, if the host is “nginx.example.com” then service configured is “nginx-deploy-main” and if the host or URL is “tea.myshop.com” then service for the same is “tea-deploy” sample applicable for the coffee service with respective service name.

• Make the DNS entries

This is the final step in which we are going to configure the DNS entries for all the three URL we have configured in the ingress resource. Basically we are going make the entries on the host machine with all the urls with ip of out haproxy container.

# lxc list haproxy
+---------+---------+-----------------------+-----------------------------------------------+------------+-----------+
|  NAME   |  STATE  |         IPV4          |                     IPV6                      |    TYPE    | SNAPSHOTS |
+---------+---------+-----------------------+-----------------------------------------------+------------+-----------+
| haproxy | RUNNING | 10.253.121.146 (eth0) | fd42:38af:bc0d:704d:216:3eff:fefa:cb4c (eth0) | PERSISTENT | 0         |
+---------+---------+-----------------------+-----------------------------------------------+------------+-----------+

So ip address of haproxy is 10.253.121.146. Simply add below entries /etc/hosts of the host machine:

# cat /etc/hosts
127.0.0.1       localhost
192.168.56.5    vbhost

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters



10.253.121.146 nginx.example.com
10.253.121.146 coffee.myshop.com
10.253.121.146 tea.myshop.com

Check the last three entries all url are pointing to haproxy which will in turn forward the request to our kubernetes worker node.

• Testing 

Now lets try to access the all URL’s one by one from the host machine.

• nginx.example.com

• tea.myshop.com

• coffee.myshop.com

So this all about the topic of How to configure ingress controller in kubernetes.

The post How to configure ingress controller in kubernetes to run multi domain-subdomain application appeared first on UX Techno.

This article will guide you about how to migrate helm v2 to helm v3 along with currently running resources in the environment.

In my previous article we have seen how to install helm version 2. Now in this article we are going to migrate currently running helm v2 configuration and its running resources to helm v3. To perform migration of helm v2 to helm v3 we are going to install plugin called 2to3 in the helm3.

Steps to migrate helm v2 to helm v3:

• Check currently running resources in helm v2

# helm ls
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
mynginx 1               Tue Jun 30 02:22:13 2020        DEPLOYED        nginx-6.0.1     1.19.0          default

# kubectl get all
NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-5bd8cb6d45-k5vlx   1/1     Running   0          54s

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP                      28d
service/mynginx      NodePort    10.103.194.212   <none>        80:30672/TCP,443:30500/TCP   54s

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   1/1     1            1           54s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-5bd8cb6d45   1         1         1       54s

• Download helm v3 binaries and unzip it.

Please note that helm v3 dont have tiller component running within kubernetes cluster.

# wget https://get.helm.sh/helm-v3.2.4-linux-amd64.tar.gz
--2020-06-30 02:24:33--  https://get.helm.sh/helm-v3.2.4-linux-amd64.tar.gz
Resolving get.helm.sh (get.helm.sh)... 152.199.39.108, 2606:2800:247:1cb7:261b:1f9c:2074:3c
Connecting to get.helm.sh (get.helm.sh)|152.199.39.108|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12926032 (12M) [application/x-tar]
Saving to: ‘helm-v3.2.4-linux-amd64.tar.gz.1’

helm-v3.2.4-linux-amd64.tar.gz.1  100%[============================================================>]  12.33M  2.73MB/s    in 4.4s

2020-06-30 02:24:39 (2.77 MB/s) - ‘helm-v3.2.4-linux-amd64.tar.gz.1’ saved [12926032/12926032]

# tar -zxvf helm-v3.2.4-linux-amd64.tar.gz
linux-amd64/
linux-amd64/helm
linux-amd64/README.md
linux-amd64/LICENSE

Now once we unzipped the file change directory to “linux-amd64”. You will find helm binary. Now we are going to copy this binary as helm3 at the location /usr/local/bin in order to differentiate between helm v2 and helm v3 binary.

# cd linux-amd64
# mv helm /usr/local/bin/helm3

Check the version details of the helm v3 binary.

# helm3 version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"
# helm3 version --short
v3.2.4+g0ad800e

just cross check whether we have currently manage chart in helm v2 and helm v3 version using helm list command as  below:

# helm3 list
NAME    NAMESPACE       REVISION        UPDATED STATUS  CHART   APP VERSION
# helm list
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
mynginx 1               Tue Jun 30 02:22:13 2020        DEPLOYED        nginx-6.0.1     1.19.0          default

As you can see that helm v3 is not managing any chart however we do have one chart deployed in helm v2 named mynginx which we are going to migrate to helm v3.

• Install plugin 2to3 in helm v3 environemnt using below command.

# helm3 plugin install https://github.com/helm/helm-2to3
Downloading and installing helm-2to3 v0.5.1 ...
https://github.com/helm/helm-2to3/releases/download/v0.5.1/helm-2to3_0.5.1_linux_amd64.tar.gz
Installed plugin: 2to3
# helm3 plugin list
NAME    VERSION DESCRIPTION
2to3    0.5.1   migrate and cleanup Helm v2 configuration and releases in-place to Helm v3

To check all the options in 2to3 plugin use help option  as below:

# helm3 2to3 help
Migrate and Cleanup Helm v2 configuration and releases in-place to Helm v3

Usage:
  2to3 [command]

Available Commands:
  cleanup     cleanup Helm v2 configuration, release data and Tiller deployment
  convert     migrate Helm v2 release in-place to Helm v3
  help        Help about any command
  move        migrate Helm v2 configuration in-place to Helm v3

Flags:
  -h, --help   help for 2to3

Use "2to3 [command] --help" for more information about a command.

As you can see that, there is move command which will migrate helm v2 to helm v3. So lets do config migration to v3.

• Perform the dry-run of the migration to check which resources or config is going to migrate to helm v3 version using command below:

# helm3 2to3 move config --dry-run
2020/06/30 02:32:35 NOTE: This is in dry-run mode, the following actions will not be executed.
2020/06/30 02:32:35 Run without --dry-run to take the actions described below:
2020/06/30 02:32:35
2020/06/30 02:32:35 WARNING: Helm v3 configuration may be overwritten during this operation.
2020/06/30 02:32:35
[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y
2020/06/30 02:32:44
Helm v2 configuration will be moved to Helm v3 configuration.
2020/06/30 02:32:44 [Helm 2] Home directory: /root/.helm
2020/06/30 02:32:44 [Helm 3] Config directory: /root/.config/helm
2020/06/30 02:32:44 [Helm 3] Data directory: /root/.local/share/helm
2020/06/30 02:32:44 [Helm 3] Cache directory: /root/.cache/helm
2020/06/30 02:32:44 [Helm 3] Create config folder "/root/.config/helm" .
2020/06/30 02:32:44 [Helm 2] repositories file "/root/.helm/repository/repositories.yaml" will copy to [Helm 3] config folder "/root/onfig/helm/repositories.yaml" .
2020/06/30 02:32:44 [Helm 3] Create cache folder "/root/.cache/helm" .
2020/06/30 02:32:44 [Helm 3] Create data folder "/root/.local/share/helm" .
2020/06/30 02:32:44 [Helm 2] starters "/root/.helm/starters" will copy to [Helm 3] data folder "/root/.local/share/helm/starters" .

As in the above output it has given all the details about migration lets perform the actual migration below command without –dry-run option.

# helm3 2to3 move config
2020/06/30 02:32:56 WARNING: Helm v3 configuration may be overwritten during this operation.
2020/06/30 02:32:56
[Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y
2020/06/30 02:32:57
Helm v2 configuration will be moved to Helm v3 configuration.
2020/06/30 02:32:57 [Helm 2] Home directory: /root/.helm
2020/06/30 02:32:57 [Helm 3] Config directory: /root/.config/helm
2020/06/30 02:32:57 [Helm 3] Data directory: /root/.local/share/helm
2020/06/30 02:32:57 [Helm 3] Cache directory: /root/.cache/helm
2020/06/30 02:32:57 [Helm 3] Create config folder "/root/.config/helm" .
2020/06/30 02:32:57 [Helm 3] Config folder "/root/.config/helm" created.
2020/06/30 02:32:57 [Helm 2] repositories file "/root/.helm/repository/repositories.yaml" will copy to [Helm 3] config folder "/root/onfig/helm/repositories.yaml" .
2020/06/30 02:32:57 [Helm 2] repositories file "/root/.helm/repository/repositories.yaml" copied successfully to [Helm 3] config fold "/root/.config/helm/repositories.yaml" .
2020/06/30 02:32:57 [Helm 3] Create cache folder "/root/.cache/helm" .
2020/06/30 02:32:57 [Helm 3] cache folder "/root/.cache/helm" created.
2020/06/30 02:32:57 [Helm 3] Create data folder "/root/.local/share/helm" .
2020/06/30 02:32:57 [Helm 3] data folder "/root/.local/share/helm" created.
2020/06/30 02:32:57 [Helm 2] starters "/root/.helm/starters" will copy to [Helm 3] data folder "/root/.local/share/helm/starters" .
2020/06/30 02:32:57 [Helm 2] starters "/root/.helm/starters" copied successfully to [Helm 3] data folder "/root/.local/share/helm/staers" .
2020/06/30 02:32:57 Helm v2 configuration was moved successfully to Helm v3 configuration.

The above command only migrates the helm v2 to helm v3. In case you want to migrate currently deployed charts from helm v2 to helm v3 you need to use convert command:

Check currently deployed charts in helm v2 using below command:

# helm list
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
mynginx 1               Tue Jun 30 02:22:13 2020        DEPLOYED        nginx-6.0.1     1.19.0          default

• Migrate the deployed charts

For the first we are going to perform dry-run.

# helm3 2to3 convert mynginx --dry-run
2020/06/30 02:33:59 NOTE: This is in dry-run mode, the following actions will not be executed.
2020/06/30 02:33:59 Run without --dry-run to take the actions described below:
2020/06/30 02:33:59
2020/06/30 02:33:59 Release "mynginx" will be converted from Helm v2 to Helm v3.
2020/06/30 02:33:59 [Helm 3] Release "mynginx" will be created.
2020/06/30 02:33:59 [Helm 3] ReleaseVersion "mynginx.v1" will be created.

We are ok with above output as its not given any error or issues while converting the deployed chart to helm v3. Now lets move the deployed resource to helm v3 without –dry-run option.

# helm3 2to3 convert mynginx
2020/06/30 02:34:22 Release "mynginx" will be converted from Helm v2 to Helm v3.
2020/06/30 02:34:22 [Helm 3] Release "mynginx" will be created.
2020/06/30 02:34:22 [Helm 3] ReleaseVersion "mynginx.v1" will be created.
2020/06/30 02:34:23 [Helm 3] ReleaseVersion "mynginx.v1" created.
2020/06/30 02:34:23 [Helm 3] Release "mynginx" created.
2020/06/30 02:34:23 Release "mynginx" was converted successfully from Helm v2 to Helm v3.
2020/06/30 02:34:23 Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 relee.
2020/06/30 02:34:23 v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated er.

To confirm migration lets use helm3 list output and also we will check pods, deployments in kubernetes using kubectl.

# helm3 list
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
mynginx default         1               2020-06-30 06:22:13.361117663 +0000 UTC deployed        nginx-6.0.1     1.19.0

----------------------------------------------------------------------------------------------------------------------------------------------
# kubectl get all -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
pod/mynginx-5bd8cb6d45-k5vlx   1/1     Running   0          12m   10.244.1.85   kworker01   <none>           <none>

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE   SELECTOR
service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP                      28d   <none>
service/mynginx      NodePort    10.103.194.212   <none>        80:30672/TCP,443:30500/TCP   12m   app.kubernetes.io/instance=mynginxpp.kubernetes.io/name=nginx

NAME                      READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                                        SELECTOR
deployment.apps/mynginx   1/1     1            1           12m   nginx        docker.io/bitnami/nginx:1.19.0-debian-10-r2   app.kubertes.io/instance=mynginx,app.kubernetes.io/name=nginx

NAME                                 DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                                        SELTOR
replicaset.apps/mynginx-5bd8cb6d45   1         1         1       12m   nginx        docker.io/bitnami/nginx:1.19.0-debian-10-r2   appubernetes.io/instance=mynginx,app.kubernetes.io/name=nginx,pod-template-hash=5bd8cb6d45

The above output confirms that we have successfully migrated deployed charts to helm v3. Now lets remove helm v2 binaries and tiller component and move back helm3 bianary to helm as a final step.

# helm3 2to3 cleanup
WARNING: "Helm v2 Configuration" "Release Data" "Tiller" will be removed.
This will clean up all releases managed by Helm v2. It will not be possible to restore them if you haven't made a backup of the releas.
Helm v2 may not be usable afterwards.

[Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y
2020/06/30 02:35:40
Helm v2 data will be cleaned up.
2020/06/30 02:35:40 [Helm 2] Releases will be deleted.
2020/06/30 02:35:40 [Helm 2] ReleaseVersion "mynginx.v1" will be deleted.
2020/06/30 02:35:41 [Helm 2] ReleaseVersion "mynginx.v1" deleted.
2020/06/30 02:35:41 [Helm 2] Releases deleted.
2020/06/30 02:35:41 [Helm 2] Tiller in "kube-system" namespace will be removed.
2020/06/30 02:35:41 [Helm 2] Tiller "deploy" in "kube-system" namespace will be removed.
2020/06/30 02:35:41 [Helm 2] Tiller "deploy" in "kube-system" namespace was removed successfully.
2020/06/30 02:35:41 [Helm 2] Tiller "service" in "kube-system" namespace will be removed.
2020/06/30 02:35:43 [Helm 2] Tiller "service" in "kube-system" namespace was removed successfully.
2020/06/30 02:35:43 [Helm 2] Tiller in "kube-system" namespace was removed.
2020/06/30 02:35:43 [Helm 2] Home folder "/root/.helm" will be deleted.
2020/06/30 02:35:43 [Helm 2] Home folder "/root/.helm" deleted.
2020/06/30 02:35:43 Helm v2 data was cleaned up successfully.
# helm list
Error: could not find tiller

So clean up done successfully also tiller component also terminated which was part of helm v2.

Now remove the helm v2 binary and move helm v3 binary as helm.

# rm -rf /usr/local/bin/helm
# mv /usr/local/bin/helm3 /usr/local/bin/helm
# helm list
NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
mynginx default         1               2020-06-30 06:22:13.361117663 +0000 UTC deployed        nginx-6.0.1     1.19.0
# helm version --short
v3.2.4+g0ad800e

So in this way we can perform migration of helm v2 to helm v3.

The post How to migrate helm v2 to helm v3 appeared first on UX Techno.

This article will explain you about helm commands along with commonly used options. You may treat this article as helm commands cheat sheet. I have explained widely used helm version 2 command in this article.

In case you want to learn about  how to install helm version please follow this article.

So here the helm commands cheat sheet list for quick go through:

• helm help

In case you want any help on command available with helm.

# helm help

Lets suppose you want more details about any command option you can use helm help <command> as below. Here in the below case we taken help on search command:

# helm help search

• helm search

In case you want to search for any chart you can helm search command for the same.

# helm search phpmyadmin
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
stable/phpmyadmin       4.3.5           5.0.1           DEPRECATED phpMyAdmin is an mysql administration frontend

• helm fetch

In case you don’t want to install the helm chart however you just want to download the chart locally then use helm along with fetch option followed by chart name as below. It will download all chart and template files in the current directory.

# helm fetch stable/phpmyadmin
# ls -ltr
total 32
-rw-r--r-- 1 root root 28921 Jun 29 11:04 phpmyadmin-4.3.5.tgz
#

• helm install 

If you want to install helm chart use install option followed by chart name . You can user –values option in case you want to use your own values.yaml file. In case you want to give it name to the deployed chart use –name option as below also chart version could be specified using –version option as below:

# helm install stable/phpmyadmin --name myphpadmin --version 4.3.3

The above command also gives overview of the resources deployed by helm in the output. In case you want to check it from the kubernetes front use below command:

# kubectl get all |grep -i myphpadmin
pod/myphpadmin-phpmyadmin-76966d4fd-wvf7l   0/1     Running   1          79s
service/myphpadmin-phpmyadmin   ClusterIP   10.99.151.168   <none>        80/TCP    80s
deployment.apps/myphpadmin-phpmyadmin   0/1     1            0           79s
replicaset.apps/myphpadmin-phpmyadmin-76966d4fd   1         1         0       79s
#

• helm status 

This command will give the curent status of the chart installation. You need to give the name of the chart which is being used in the helm install command as below:

# helm status myphpadmin

• helm list

To list down currently deployed chart use helm list command.

# helm list
NAME            REVISION        UPDATED                         STATUS          CHART                   APP VERSION     NAMESPACE
myphpadmin      1               Mon Jun 29 11:35:32 2020        DEPLOYED        phpmyadmin-4.3.3        5.0.1           default
#

• helm upgrade 

In case you want to upgrade the current version of helm chart, use upgrade command. In our helm install example we installed version 4.3.3 now we will upgrading the chart to 4.3.4 version using below command.

# helm upgrade myphpadmin stable/phpmyadmin --version 4.3.4

• helm history 

To check the history of the chart installed use command helm history followed by chartname.

# helm history myphpadmin
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Jun 29 11:35:32 2020        SUPERSEDED      phpmyadmin-4.3.3        5.0.1           Install complete
2               Mon Jun 29 11:53:48 2020        DEPLOYED        phpmyadmin-4.3.4        5.0.1           Upgrade complete
#

• helm rollback

In case you are not happy with upgraded version and you want to rollback to previous version use helm rollback  along with revision number as below:

# helm rollback myphpadmin 1
Rollback was a success.
#

• helm delete 

To delete the installed chart use helm delete command as below:

# helm delete myphpadmin
release "myphpadmin" deleted
#

• helm repo list

To list down currently used repositories use helm repo list command.

# helm repo list
NAME    URL
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts
#

• helm repo update

To update repositories use helm repo update command.

# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.
#

• helm reset

If you want to uninstall the tiller component use command  helm reset along with option “–remove-helm-home” in case you want to remove the home directory of the helm. Also -f option to do it forcefully.

# helm reset -f --remove-helm-home
Deleting /root/.helm
Tiller (the Helm server-side component) has been uninstalled from your Kubernetes Cluster.
#

To explore more commands follow this link.

The post Helm commands cheat sheet appeared first on UX Techno.

This article will guide you on how to install helm in kubernetes cluster. You might be aware that Helm is the package manger that can be deployed in kubernetes.

Using Helm you can deploy application and manage them easily.To read more about the helm please follow this link.

To show case the demo, we are going to install helm version 2 so that later may be we can see other post which can guide us on how to migrate to helm version 3.

Steps:

• Create the service account required.

# kubectl create serviceaccount --namespace kube-system tiller
serviceaccount/tiller created

•  Create the cluster role binding in the cluster.

# kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller created

• Download the helm binaries and extract it. In this case we are installing helm version 2.16.9

# wget https://get.helm.sh/helm-v2.16.9-linux-amd64.tar.gz
# tar -zxvf helm-v2.16.9-linux-amd64.tar.gz
# cd linux-amd64/
# ls -ltr
total 78672
-rwxr-xr-x 1 root root 39919616 Jun 16 14:17 helm
-rwxr-xr-x 1 root root 40615936 Jun 16 14:20 tiller
-rw-r--r-- 1 root root     3444 Jun 16 14:20 README.md
-rw-r--r-- 1 root root    11343 Jun 16 14:20 LICENSE

• Now move the helm binary to /usr/local/bin

# mv helm /usr/local/bin/helm

• Check the version of the helm.

# which helm
/usr/local/bin/helm
# helm version
Client: &version.Version{SemVer:"v2.16.9", GitCommit:"8ad7037828e5a0fca1009dabe290130da6368e39", GitTreeState:"clean"}
Error: could not find tiller
# helm version --short
Client: v2.16.9+g8ad7037

• Initialize the helm using helm init command as below.

# helm init --service-account tiller
Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://v2.helm.sh/docs/securing_installation/

• Cross check that tiller is running fine in the kubernetes using below command.

# kubectl -n kube-system get pod,deploy|grep -i tiller
pod/tiller-deploy-8488d98b4c-9xpbg    1/1     Running   0          14s
deployment.apps/tiller-deploy   1/1     1            1           14s

• Once you see that tiller is running fine fire helm list command to cross verify. In the beginning it will show blank output.

# helm list

Some other commands to cross verify your helm:

# helm search jenkins
NAME            CHART VERSION APP VERSION       DESCRIPTION
stable/jenkins  2.1.0         lts               Open source continuous integration server. It supports mu...
# helm home
/root/.helm
# helm version --short
Client: v2.16.9+g8ad7037
Server: v2.16.9+g8ad7037
# helm repo list
NAME    URL
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts

In case you want to install jenkins use below command:

# helm install stable/jenkins

Once installed you can list down it using below helm list command:

# helm list
NAME         REVISION   UPDATED                  STATUS      CHART             APP VERSION  NAMESPACE
khaki-kitten 1          Thu Jun 25 02:05:27 2020 DEPLOYED    jenkins-2.1.0     lts          default

So this is all about “How to install helm” in kubernetes and cross-verify it for successful installation.

The post How to install helm in kubernetes cluster appeared first on UX Techno.