Im not clear with the use of --record in kubectl command.
kubectl run nginx image=nginx --port=80 --record
detailed explanation with an example is much appreciated.
Using the --record flag when using kubectl annotates the objects created with that command with the command used to create them. When you list/retrieve these objects, the annotations will show up so that objects can be associated with a command.
I should warn you, however, that there is talk of deprecating this flag in the Kubernetes official repository here
https://github.com/kubernetes/kubernetes/pull/20035
and here
https://github.com/kubernetes/kubernetes/issues/40422
Related
I am using helm to deploy my applications which has deployments, pods and jobs and others.
Is there any way to get "kubectl describe" output of all objects loaded by "helm install" ?
Tell me if it is working, but I tried with my helm charts (custom one, ES and kibana).
TL;DR
kubectl get all -l chart=myb5 -n myb5
-n stands for namespace
-l stands for label
Explanations
Labeling your kubernetes objects is really important, and most of the helm charts out there are using labels to easily access and select objects.
When you install a chart, it adds a label such chart=my-chart-name. If the chart is not using it (maybe you are creating one for yourself), it is a good practice to add it.
So querying all resources with get all should retrieve all the resources created in the default namespace.
Depending where you installed your helm chart, it is good to add the namespace field in your query.
Note that if you use 1 namespace for only 1 helm chart resources, you do not need to filter with labels.
PS: should work the same with describe ;)
Best,
Since you're using helm install, i assume your Chart's resources are installed into a specific namespace.
In that case, you can simply use the command kubectl describe all -n <your-namespace>.
Its output should be the same as using kubectl describe on each resource of your Helm Chart.
kubectl describe all -l chart=<chartName> -n namespace
or
kubectl get events -n namespace -w
I tried to find useful information when should i use --record. I created 3 commands:
k set image deployment web1 nginx=lfccncf/nginx:latest --record
k rollout undo deployment/web1 --record
k -n kdpd00202 edit deployment web1 --record
Could anyone tell me if I need to use --record in each of these 3 commands?
When is it necessary to use --record and when is it useless?
Kubernetes desired state can be updated/mutated thru two paradigms :
Either imperatively using kubectl adhoc commands ( k set, k create, k run, k rollout ,..)
Or declaratively using YAML manifests with a single k apply
The declarative way is ideal for treating your k8s manifests as Code, then you can share this Code with the team, version it thru Git for example, and keep tracking its history leveraging GitOps practices ( branching models, Code Review, CI/CD ).
However, the imperative way cannot be reviewed by the team as these adhoc-commands will be run by an individual and no one else can easily find out the cause of the change after the change has been made.
To overcome the absence of an audit trail with imperative commands, the --record option is there to bind the root cause of the change as annotation called kubernetes.io/change-cause and the value of this annotation is the imperative command itself.
(note below is from the official doc)
Note: You can specify the --record flag to write the command executed in the resource annotation kubernetes.io/change-cause. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
As conclusion :
Theoretically ,--record is not mandatory
Practically, it's mandatory in order to ensure the changes leave a rudimentary audit trail behind and comply with SRE process and DevOps culture.
You can specify the --record flag to write the command executed in the resource annotation kubernetes.io/change-cause. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
kubectl rollout history deployment.v1.apps/nginx-deployment
The output is similar to this:
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
So it's not mandatory for any of the commands and but is recommended for kubectl set image because you will not see anything in CHANGE-CAUSE section as above if you skip --record
--record flag also helps to see the details of the revision history, so rollback to a previous version also would be smoother.
When you don't append --record flag Change-Cause table will be just <none> in
kubectl rollout history
$ kubectl rollout history deployment/app
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
I'm new to k8s and I'm trying to learn how to setup deployments.
I'm searching for a way to create a new deployment without any images. Over time, I will add new (0 or more) images (and specify thier desired state). As I don't know what images the deployment will contain in advance, I can't use any existing configuration files.
Is it possible? If yes, how?
If it's possible, a command-line solution will be great.
If you want to start a single instance of nginx, you can do
$ kubectl run nginx --image=nginx
But it is not possible to create any deployments without image.
$ kubectl run demo --image=""
error: --image is required
If you want to edit your existing deployment, then you can run
$ kubectl edit deployments <deployment-name> -n <namespace>
You can also patch container with new image to existing deployments by running following command
$ kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"myapp","image":"newimage"}]}}}}'
To replace image of a containers in deployment, run
$ kubectl set image deployment/<deployment-name> <container-name>=<image>
One of the points in the kubectl best practices section in Kubernetes Docs state below:
Pin to a specific generator version, such as kubectl run
--generator=deployment/v1beta1
But then a little down in the doc, we get to learn that except for Pod, the use of --generator option is deprecated and that it would be removed in future versions.
Why is this being done? Doesn't generator make life easier in creating a template file for resource definition of deployment, service, and other resources? What alternative is the kubernetes team suggesting? This isn't there in the docs :(
kubectl create is the recommended alternative if you want to use more than just a pod (like deployment).
https://kubernetes.io/docs/reference/kubectl/conventions/#generators says:
Note: kubectl run --generator except for run-pod/v1 is deprecated in v1.12.
This pull request has the reason why generators (except run-pod/v1) were deprecated:
The direction is that we want to move away from kubectl run because it's over bloated and complicated for both users and developers. We want to mimic docker run with kubectl run so that it only creates a pod, and if you're interested in other resources kubectl create is the intended replacement.
For deployment you can try
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
and
Note: kubectl run --generator except for run-pod/v1 is deprecated in v1.12.
I am kubernetes newbie, and I have a basic question
my understanding from https://kubernetes.io/docs/reference/kubectl/conventions/ is , we can generate yaml templates using "kubernetes run" command
But when I tried doing same, it didn't work as expected
kubectl run deployment-sample --image deployment-sample --dry-run -o yaml --generator=extensions/v1beta1
error: generator "extensions/v1beta1" not found
kubectl run deployment-sample --image deployment-sample --dry-run -o yaml --generator=apps/v1beta1
error: generator "apps/v1beta1" not found
Not sure if my understanding is wrong or something wrong in my command ?
I am on kubernetes 1.11
I find that I can create a Deployment with kubectl run --generator=deployment/v1beta1 foobar --image=nginx -o yaml --dry-run so your case would be kubectl run --generator=deployment/v1beta1 deployment-sample --image=deployment-sample -o yaml --dry-run. The kubectl conventions page you refer to does say this generator is 'recommended' for Deployments.
But I'm not sure why the docs list a non-recommended generator option that actually doesn't work. For a command like this you can recreate the expected output in a reference environment through the online tutorials at https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/ You get the same output there so it is not just you or your cluster. My best guess is that 'extensions/v1beta1' is too general to match to a deployment specifically. It could well be that the documentation needs changing on this.