I am surprised that nobody has yet asked this, but what exactly is deployment.apps?
I see it often in commands e.g
kubectl rollout pause deployment.apps/nginx-deployment
or even used interchangably for the deployments keyword:
kubectl get deployments= kubectl get deployment.apps
I do not understand what it indicates though. Even in K8s official docs, they just take for granted that the reader understands the term.
Could someone please explain it to me?
Kubernetes API has its different resources (e.g. Pods, Deployments, Ingress) grouped in what they call "api groups" and in the notation deployment.apps - "deployment" is the resource name and the "apps" is the api group name.
Also see the motivation for API groups
Related
I am studying "kubectl describe" sourcecodes at https://github.com/kubernetes/kubectl/blob/master/pkg/describe/describe.go
However, I still could not figure out how "kubectl decsribe [CRD]" works (as in which function/functions are called).
I am a Go newbie, so would like to get some pointers please. Thanks.
I have read describePod function and understand how it works more or less, but still could not figure out how "kubectl describe [CRD]" works.
The "kubectl describe " function can be found in the command-line interface (CLI) of Kubernetes, specifically in the "kubectl" tool. "kubectl" is used to manage and interact with a Kubernetes cluster and its resources.
enter image description here
Kubectl describe command helps to view the entire information about the kubernetes resources like Pods,deployments,services,nodes,jobs etc.
By using CRD(Custom Resource Definition) you can do CRUD operations like create, update, get and delete commands to access the resources. To use CRD we need to use the API groups.
Example:
Suppose you specify an API group as example.crd.com, which means you can issue the get, list, create, update, and delete commands to access the custom resources under the API group example.crd.com.
You can use kubectl describe crd <crd_name> to get a description of the CRD.
For more information refer this official doc
Try this similar SO’s SO1 and SO2 for more information
I cannot for the life of me find a detailed table of what all the Kubernetes RBAC verbs do. The only resource I see people recommending is this one, which is woefully inadequate.
So I've been working it out by experimentation.
Most are fairly straightforward so far, except for UPDATE. This does not seem to be able to do anything I would expect it to.
Permissions I gave my alias:
[GET, UPDATE] on [deployments] in default namespace.
Things I've tried:
kubectl set image deployment/hello-node echoserver=digitalocean/flask-helloworld --as user
kubectl edit deploy hello-node --as user
kubectl apply -f hello-node.yaml --as eks-user
These all failed with error: deployments.apps "hello-node" is forbidden: User "user" cannot patch resource "deployments" in API group "apps" in the namespace "default"
I then tried some rollout commands like:
k rollout undo deploy hello-node --as user
But they failed because I didn't have replica-set access.
TLDR: What is the point of the Kubernetes RBAC update verb?
For that matter, does anyone have a more detailed list of all RBAC verbs?
Following up this, I went to the Kubernetes REST API documentation, which has a long list of all the HTTP API calls you can make to the REST server.
I thought this would help because the one (1) table available describing what the different verbs can do did so by comparing them to HTTP verbs. So the plan was:
See what HTTP verb the update permission is equated to.
Go to the reference and find an example of using that HTTP verb on a deployment.
Test the kubectl equivalent.
So.
What HTTP verb equals the update permission?
PUT.
Example of using PUT for deployments?
Replace Scale: replace scale of the specified Deployment
HTTP Request
PUT /apis/apps/v1/namespaces/{namespace}/deployments/{name}/scale
What's the equivalent kubectl command?
Well we're scaling a deployment, so I'm going to say:
kubectl scale deployment hello-node --replicas=2
Can I run this command?
I extended my permissions to deployment/scale first, and then ran it.
Error from server (Forbidden): deployments.apps "hello-node" is forbidden: User "user" cannot patch resource "deployments/scale" in API group "apps" in the namespace "default"
Well. That also needs patch permissions, it would appear.
Despite the fact that the HTTP verb used is PUT according to the API docs, and PUT is equivalent to update according to the one (1) source of any information on these RBAC verbs.
Anyway.
My Conclusion: It appears that update is indeed pretty useless, at least for Deployments.
The RBAC setup seemed promising at first, but honestly it's starting to lose its lustre as I discover more and more edge cases and undocumented mysteries. Access permissions seem like the absolute worst thing to be vague about, or your security ends up being more through obscurity than certainty.
You can get a dump of the "allowed/supported" verbs using this krew plugin rbac-tool
# Generate a ClusterRole with all the available permissions for core and apps api groups
$ kubectl rbac-tool show --for-groups=,apps
While it won't tell you exactly the semantics of each verb - it will give yu a sense about the RBAC permissions universe your cluster have.
Hoping for some pointers, I have a question: what role/permissions do I need to add to a user that has Clusterrole:view in order to let that user use 'top node' and 'top pod' command in kubectl? We're using kubectl version 1.15.x (client) on a 1.15.7 cluster (AKS), although I'm not sure if that's relevant information.
I tried to find this in the k8s documentation, but could not find the permission-reference descrption, only some examples and guidelines.
Thanks in advance!
Regards, Ludo
There is no specific permission for top node and top pod. The permission is on whether you can do get nodes and get pods. If permission is there to do get nodes and get pods then you should be able to top nodes and top pods as well. Permission to perform get nodes or get pods is defined via RBAC in kubernetes.
The metric server just exposes metrics of different resources such as pods, nodes by collecting and aggregating it from different sources such as kubelet. That's the reason there is no permission for the metrics itself rather the permission is on the resources of which you want to see the metrics.
The API that is being invoked when you do kubectl top pods is this
GET https://API-SERVER-IP:6443/apis/metrics.k8s.io/v1beta1/namespaces/default/pods
So you can only see metrics for pods in the default namespace when you are targeted to default namespace. Now whether you can get pods in default namespace is governed by RBAC.
First off, I'm completely new with Kubernetes so I may have missed something completely obvious but the documentation is exactly helping, so I'm turning to you guys for help.
I'm trying to figure out just how many types of "deployment files" there are for Kubernetes. I call them "deployment files" because I really don't know what else to call them and they're usually associated with a deployment.
So far, every yml/yaml file I've seen start like this:
apiVersion:
kind: << this is what I'm asking about >>
metadata:
And so far I have seen this many "kind"(s)
ClusterConfig
ClusterRole
ClusterRoleBinding
CronJob
Deployment
Job
PersistentVolumeClaim
Pod
ReplicationController
Role
RoleBinding
Secret
Service
ServiceAccount
I'm sure there are many more. But I can't seem to find a location where they are listed and the contexts broken down.
So what I want to know is this,
Where can I find an explanation for these yaml files?
Where can I learn about the different kinds?
Where can I get a broken down explanation of the minimum required fields/values are for any of these?
Are there templates for these files?
Thanks
This question will need a blog to answer but still in short you can try these options and command to learn from your kubectl CLI.
Learn to use kubectl explain command which shows you a list of Kubernetes objects:
$ kubectl explain
You can get detailed information about any of listed resources using this syntax
`$ kubectl explain pod
$ kubectl explain pod.spec
$ kubectl explain pod.spec.containers`
Or you can get yam template of the object by adding --recursive flag to explain command.
$ kubectl explain pod --recursive
This will also give you official document link.
So in short running kubectl explain with recursive option will list every thing.
When you are talking about specific yaml file containing the definition of specific kubernetes object, you can call them yaml manifests or simply yaml definition files. Using word Deployment for all of them isn't a good idea as there is already specific resource type defined and called by this name in kubernetes. So it's better you don't call them all deployments for consistency.
I'm sure there are many more. But I can't seem to find a location
where they are listed and the contexts broken down.
Yes, there are a lot more of them and you can list those which are available by running:
kubectl api-resources
These different objects are actually called api-resources. As you can see they are listed in three columns: NAME, SHORTNAMES, APIGROUP, NAMESPACED and KIND
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
Note that the name of resource corresponds to its KIND but it is slightly different. NAME simply describes resource types as we are referring to them e.g. using kubectl command line utility. Just to give one example, when you want to list pods available in your cluster you simply type kubectl get pods. You don't have to use resource kind i.e. Pod in this context. You can but you don't have to. So kubectl get Pod or kubectl get ConfigMap will also return desired result. You can also refer to them by their shournames so kubectl get daemonsets and kubectl get ds are equivalent.
It's totally different when it comes to specific resource/object definition. In context of yaml definition file we must to use proper KIND of the resource. They are mostly start with capital letter and are written by co called CamelCase but there are exceptions from this rule.
I really recommend you to familiarize with kubernetes documentation. It is very user-friendly and nicely explains both key kubernetes concepts as well as all very tiny details.
Here you have even more useful commands for exploring API resources:
kubectl api-resources --namespaced=true # All namespaced resources
kubectl api-resources --namespaced=false # All non-namespaced resources
kubectl api-resources -o name # All resources with simple output (just the resource name)
kubectl api-resources -o wide # All resources with expanded (aka "wide") output
kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
As #wargre already suggested in his comment, kubernetes official documentetion is definitely the best place to start as you will find there very detailed description of every resource.
Understanding Kubernetes Objects
You may start from reading this article: Understanding Kubernetes Objects
Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
What containerized applications are running (and on which nodes)
The resources available to those applications
The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
A Kubernetes object is a “record of intent”–once you create the object, the Kubernetes system will constantly work to ensure that object exists. By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
K8s API reference
A detailed description of all objects can be found in the Kubernetes API reference guide.
While there's a lot of documentation and examples on Kubernetes RBAC and also the available verbs for different resources, I couldn't find any rules on whether certain verbs are always used in combination or whether there are use cases to using them individually. In particular, I'm wondering about the verbs get, list, and watch. What uses are for combining them, and especially not combining them?
are there uses for allowing get on resources, but not list?
au contraire, are there uses for list without allowing get? Maybe along the lines of information sparseness?
get and list, but no watch? To restrict only trusted subjects and service accounts to put more strain on the API server and etcd?
watch without list or get? Wouldn't that cripple most clients because they're listwatchers?
Interesting question, here are some ideas and examples of usages in practice.
There are many more examples in practice. For example, you can inspect the default ClusterRoles by browsing through kubectl describe clusterroles. And to see which API requests kubectl makes under the hood, you can increase the log verbosity, for example, kubectl get pods -w -v 10.
get but not list
You want someone to be able to read resources they know by name but not discover what other resources exist. For example, allows to do kubectl get mypod, but not kubectl get pods.
Examples:
The system:node ClusterRole has get but not list permissions on Endpoints, PVs, and PVCs.
The system:coredns ClusterRole has get but not list permissions on Nodes.
The system:controller:expand-controller ClusterRole has get but not list permissions on Endpoints, Secrets, and Services.
list but not get
Allows to do, for example, kubectl get pods but not kubectl get pod mypod. It doesn't make much sense, because all the information you can get with get is also included in list. Nevertheless, there are some usages of this in practice.
Examples:
The system:kube-dns ClusterRole has list and watch permissions for Endpoints and Services, but not get.
The system:controller:daemon-set-controller ClusterRoel has list and watch permissions for Nodes, but not get.
The system:coredns ClusterRole has list and watch permissions for Endpoints, Namespaces, Pods, and Services, but not get.
get and list, but not watch
In practice, in most cases where there is list there is also watch. You could deprive someone of watch to reduce the number of watchers on etcd. Users can do kubectl get pods and kubectl get pods mypod, but not use the -w option.
Makes also sense if the API does not support watch operations, like, for example, the optional metric APIs.
Examples:
The system:controller:persistent-volume-binder ClusterRole has get and list permissions for Nodes, but not watch
watch, but not get and list
Regarding the use case, it doesn't make much sense, because all the information you can get with get and list is also included in watch. I don't know of any concrete usage of this in practice.
However, technically, it's possible. For example, if you have watch permissions for Pods, but not get and list, you can do:
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods"
✅ kubectl get --raw="/api/v1/watch/namespaces/default/pods/mypod"
And it works. However, these watch endpoints are deprecated and you should use the list endpoint with a watch parameter instead. But this also works:
✅ kubectl get --raw="/api/v1/namespaces/default/pods?watch=true"
However, you can't watch a single Pod like this, because the get endpoint doesn't have a watch parameter. So, the following is invalid:
❌ kubectl get --raw="/api/v1/namespaces/default/pods/mypod?watch=true"
And you can't watch resources with kubectl at all. The following fails:
❌ kubectl get pods -w
❌ kubectl get pods mypod -w
Because kubectl makes a list and get request, respectively, before the watch request, most probably to get the resourceVersion of the resources which will then be included in the subsequent watch request.
Note: that means, if you have list and watch, then kubectl get pods -w works, but kubectl get pods mypod -w doesn't, and if you have get and watch, then kubectl get pods mypod -w works but kubectl get pods -w doesn't.