I am building an application which should execute tasks in a separate container/pods.
this application would be running in a specific namespace the new pods must be created in the same namespace as well.
I understand we can similar via custom CRD and Operators, but I found it is overly complicated and we need Golang knowledge for the same.
Is there any way this could be achived without having to learn Operators and GoLang?
I am ok to use kubctl or api within my container and wanted to connect the host and to the same namespace.
Yes, this is certainly possible using a ServiceAccount and then connecting to the API from within the Pod.
First, create a ServiceAccount in your namespace using
kubectl create serviceaccount my-service-account
For your newly created ServiceAccount, give it the permissions you want using Roles and RoleBindings. The subject would be something like this:
subjects:
- kind: ServiceAccount
name: my-service-account
namespace: my-namespace
Then, add the ServiceAccount to the Pod from where you want to create other Pods from (see documentation). Credentials are automatically mounted inside the Pod using automountServiceAccountToken.
Now from inside the Pod you can either use kubectl or call the API using the credentials inside the Pod. There are libraries for a lot of programming languages to talk to Kubernetes, use those.
Related
What is the difference between $kubectl create deploy and $kubectl create deployment? Google Cloud Fundamental's Lab is using kubectl create deploy command, but in the Kubernetes documentation/Interactive Tutorial (https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive/), it is using the command kubectl create deployment. So just wanted to ask this group, which one is the correct/latest?
The kubectl create deploy and kubectl create deployment commands both create a deployment in Kubernetes. The only difference is that the kubectl create deploy command is a shorthand version of the kubectl create deployment command. The kubectl create deployment command is the more verbose version and provides more options for creating a deployment.
The two commands are effectively interchangeable and both will create a Kubernetes deployment.Ultimately, it is up to the user to decide which syntax to use, as long as the deployment is created successfully.
As #gohmc and #fcmam5 said, The kubectl api-resources command prints a list of all of the available API resources in the Kubernetes cluster. The list includes the resource name, the kind of resource it is, and the API version it belongs to. Here is an example of the output of the command:
NAME KIND APIVERSION
bindings Binding v1
configmaps ConfigMap v1
endpoints Endpoints v1
events Event v1beta1
limitranges LimitRange v1
namespaces Namespace v1
pods Pod v1
replicationcontrollers ReplicationController v1
resourcequotas ResourceQuota v1
secrets Secret v1
services Service v1
As per this SO, you can also kubectl api-resources -o wide shows all the resources, verbs and associated API-group.
For more information refer to this kubernetes cheatsheet
They meant the same. You can find the SHORTNAMES for K8s resource with kubectl api-resources.
These deploy is a short-name for deployment, same as po for pod, you can see the full list of commands and their shortened versions with:
kubectl api-resources
When you create a new namespace in Kubernetes there always will be a default-token secret available in it.
$ kubectl create namespace test
$ kubectl get secrets -n test
NAME TYPE DATA AGE
default-token-wh7hv kubernetes.io/service-account-token 3 6m10s
Question:
How can I create a secret that will be always available (as in above example) in newly created namespace?
default-token is used within the cluster and managed by the cluster.
ServiceAccounts are intended to provide an identity for a Kubernetes Pod to be used by its container to authenticate and authorize them when performing API-requests to the Kubernetes API-server. Default ServiceAccount will be created when you create namespace.
Secret resources reside in a namespace. Secrets can only be referenced by Pods in that same namespace.
If you want a way to create your own secret when additional ns created for that you will need an extra utility.
You can write a code to communicate with K8s API
Check the namespace list periodically.
Create a secret when an additional namespace created.
Why can't we create PV or PVC in imperative way?
Trying using create command, but it doesn't show any of them.
kubectl create --help
Available Commands:
clusterrole Create a ClusterRole.
clusterrolebinding Create a ClusterRoleBinding for a particular ClusterRole
configmap Create a configmap from a local file, directory or literal value
cronjob Create a cronjob with the specified name.
deployment Create a deployment with the specified name.
ingress Create an ingress with the specified name.
job Create a job with the specified name.
namespace Create a namespace with the specified name
poddisruptionbudget Create a pod disruption budget with the specified name.
priorityclass Create a priorityclass with the specified name.
quota Create a quota with the specified name.
role Create a role with single rule.
rolebinding Create a RoleBinding for a particular Role or ClusterRole
secret Create a secret using specified subcommand
service Create a service using specified subcommand.
serviceaccount Create a service account with the specified name
As described in the documentation kubectl uses imperative commands built into the kubectl command-line tool in order to help you creating objects quickly.
After some checks it seems like this is not available because it has not been implemented yet. You can see the full list of the create options at kubectl/pkg/cmd/create.
For example, #78153 was responsible for kubectl create ingress functionality.
You would probably get more information and perhaps reasons why this is not implemented by asking the developers and opening a new issue.
I'm looking to create yaml files for specific resources (pvs, pvcs, policies and so on) via the command line with kubectl.
kubectl create only supports the creation of certain resource types (namely clusterroles, clusterrolebindings, configmaps, cronjobs, deployments, jobs, namespaces, pod disruption budgets, priorityclasses, quotas, roles, rolebindings, secrets, services and serviceaccounts).
Why doesn't it support pods, pvs, pvcs, etc?
I know of kubectl run --generator=run=pod/v1 for pods, but is there a specific reason it hasn't been added to kubectl create?
I searched the docs and github issues, but couldn't find an explanation.
I know of tools like ksonnet, but I was wondering if there is a native way (or a reason why there isn't).
You can create any type of object with kubectl create. To do that you have two solutions :
Using a file descriptor : kubectl create -f my-pod-descriptor.yml
Using stdin (where your file content is in fact in your console) :
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
EOF
Now back to the question, as to why didn't they add a kubectl create pod command for example. I don't really have the answer.
My guess is because it is not really a good practice to manage pods directly. It is recommended to use deployments instead. And you have a kubectl create deployment command.
What about other objects wich are perfectly fine such as pv or pvc. Well, I don't know :)
Just keep in mind that it is not really a good practice to create/manage everything from the console, as you won't be able to keep the history of what you are doing. Prefer using files managed in a SCM.
Thus, I guess the K8S team is not putting too much an effort in a procedure or command that is not recommended. Which is fine to me.
I am using Google cloud's GKE for my kubernetes operations.
I am trying to restrict access to the users that access the clusters using command line. I have applied IAM roles in Google cloud and given view role to the Service accounts and users. It all works fine if we use it through api or "--as " in kubectl commands but when someone tries to do a kubectl create an object without specifying "--as" object still gets created with "default" service account of that particular namespace.
To overcome this problem we gave restricted access to "default" service account but still we were able to create objects.
$ kubectl auth can-i create deploy --as default -n test-rbac
no
$ kubectl run nginx-test-24 -n test-rbac --image=nginx
deployment.apps "nginx-test-24" created
$ kubectl describe rolebinding default-view -n test-rbac
Name: default-view
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: view
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount default test-rbac
I expect users who are accessing cluster through CLI should not be able to create objects if they dont have permisssions, even if they dont use "--as" flag they should be restricted.
Please take in count that first you need to review the prerequisites to use RBAC in GKE
Also, please note that IAM roles applies to the entire Google Cloud project and all clusters within that project and RBAC enables fine grained authorization at a namespace level. So, with GKE these approaches to authorization work in parallel.
For more references, please take a look on this document RBAC in GKE
For all the haters of this question, I wish you could've tried pointing to this:
there is a file at:
~/.config/gcloud/configurations/config_default
in this there is a option under [container] section:
use_application_default_credentials
set to true
Here you go , you learnt something new.. enjoy. Wish you could have tried helping instead of down-voting.