Rename- Azure VM

This post i am writing after the issue faced during the DR set-up & now you might be wondering how come DR set up is connected to the caption. Well it is and let me explain you how.

During the time of DR set up , ASR was showing the VM to enable to replication but it was showing Grayed out and you can not choose it or select it. I followed my own article on this scenario but still unable to fix then i dig it further and found all VMs are created from disk except this one which was created from Image. Below is the post on similar issues -

https://pachehra.blogspot.com/2019/08/vm-migration-between-regions-via-asr.html


All VM's where we could enable the replication without issue showing source as Disk because all VMs were migrated from On-prem via ASR. Only this VM showing image and also grayed out during DR set-up.

Now i tried to re-deploy the VM just to be sure as i have already followed mentioned in the above article of mine. This did not fix the issue but yes gave me the well defined error, which helped to figure out why source was image.



Hence my question to the tech who was working on the fail-over during migration regarding the Source being Image because i knew as per the error this VM was not generalized but created from the captured image of running VM. My only motive was just to know what was the reason that he needs to go through the Capture image and re-create the VM.


Guess what was the Answer -

May be you guessed right. He said needed to change the name on the VM as during migration he forgot to change the name and i was like - you dont need to capture to change the name , hence the caption and better way to do it.

Best way to change the name is - Delete  the VM and re-create from the left-over Disk , you do have option to create the VM  "easy-peasy"




So the essence of the story - Best way to change the Azure VM name is to delete the existing VM and create the VM from the left-over disk as shown in the Snippet.


Kubernetes - Imperative Commands with kubectl

This post is more like a quick summary or guide for the imperative commands that would help you many ways especially during the certification so without wasting time lets dive into it.


POD
Create an NGINX Pod: this would create the NGINX pod-

Kubectl run --generator=run-pod/v1 nginx --image=nginx


(This will automatically use the pod's labels as selectors)



Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

kubectl run --generator=run-pod/v1 nginx --image=nginx --dry-run -o yaml

 


Deployment 

Create a deployment

kubectl run --generator=deployment/v1beta1 nginx --image=nginx

Or the newer recommended way: 

kubectl create deployment --image=nginx nginx

 

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)

kubectl run --generator=deployment/v1beta1 nginx --image=nginx --dry-run -o yaml

Or

kubectl create deployment --image=nginx nginx --dry-run -o yaml

 

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run) with 4 Replicas (--replicas=4)

kubectl run --generator=deployment/v1beta1 nginx --image=nginx --dry-run --replicas=4 -o yaml

kubectl create deployment does not have a --replicas option. You could first create it and then scale it using the kubectl scale command.

 

Save it to a file - (If you need to modify or add some other details)

kubectl run --generator=deployment/v1beta1 nginx --image=nginx --dry-run --replicas=4 -o yaml > nginx-deployment.yaml

 

Service

Create a Service named redis-service of type ClusterIP to expose pod redis on port 6379

kubectl expose pod redis --port=6379 --name redis-service --dry-run -o yaml

(This will automatically use the pod's labels as selectors)



Create a Service named nginx of type NodePort to expose pod nginx's port 80 on port 30080 on the nodes:

kubectl expose pod nginx --port=80 --name nginx-service --dry-run -o yaml

(This will automatically use the pod's labels as selectors, but you cannot specify the node port. You have to generate a definition file and then add the node port in manually before creating the service with the pod.)

Or

kubectl create service nodeport nginx --tcp=80:80 --node-port=30080 --dry-run -o yaml

(This will not use the pods labels as selectors)

Both the above commands have their own challenges. While one of it cannot accept a selector the other cannot accept a node port. I would recommend going with the `kubectl expose` command. If you need to specify a node port, generate a definition file using the same command and manually input the nodeport before creating the service.

 

Reference:

https://kubernetes.io/docs/reference/kubectl/conventions/



--dry-run: By default as soon as the command is run, the resource will be created. If you simply want to test your command , use the --dry-run option. This will not create the resource, instead, tell you weather the resource can be created and if your command is right.
-o yaml: This will output the resource definition in YAML format on screen.

 

Risk Vs Constraints

 The distinction between risks and constraints lies in their nature and impact on the project. Here's how they differ: 1. Nature Risks...