I tried to run a config file to set Falco as my backend webhook. Iam getting this error on trying to run my config file
revaa#revaa-Lenovo-E41-25:~/opa$ kubectl apply -f conflc.yaml
error: unable to recognize "conflc.yaml": no matches for kind "Config" in version "v1"
Here is my config file
apiVersion: v1
kind: Config
clusters:
- name: falco
cluster:
server: http://$FALCO_SERVICE_CLUSTERIP:8765/k8s_audit
contexts:
- context:
cluster: falco
user: ""
name: default-context
current-context: default-context
preferences: {}
users: []
How to fix this?
The object Config is not a server side configuration. Instead, it is used for your kubectl (in general) to know where it should interact with.
You can check out the documentation about context here. This will let you understand how to manage the cluster with the object Object inside your local machine.
In the case that you want to add the configuration to your application, what you need is the ConfigMap, which is the object under Kubernetes server side.
You can check out more information about ConfigMap in this doc.
Related
I want to add a new cluster in addition to the default cluster on ArgoCD but when I add it, I get an error:
FATA[0001] rpc error: code = Unknown desc = REST config invalid: the server has asked for the client to provide credentials
I use the command argocd cluster add cluster-name
I download config file k8s of Rancher.
Thanks!
I solved my problem but welcome other solutions from everyone :D
First, create a secret with the following content:
apiVersion: v1
kind: Secret
metadata:
namespace: argocd # same namespace of argocd-app
name: mycluster-secret
labels:
argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
name: cluster-name # Get from clusters - name field in config k8s file.
server: https://mycluster.com # Get from clusters - name - cluster - server field in config k8s file.
config: |
{
"bearerToken": "<authentication token>",
"tlsClientConfig": {
"insecure": false,
"caData": "<base64 encoded certificate>"
}
}
bearerToken - Get from users - user - token field in config k8s file.
caData - Get from clusters - name - cluster - certificate-authority-data field in config k8s file.
Then, apply this yaml file and the new cluster will be automatically added to ArgoCD.
I found the solution on github:
https://gist.github.com/janeczku/b16154194f7f03f772645303af8e9f80
THE PLOT:
I am working on a kubernetes environment where we have PROD and ITG setup. The ITG setup has multi-cluster environment whereas PROD setup is a single-cluster environment.
I am trying to automate some process using Python where I have to deal with kubeconfig file and I am using the kubernetes library for it.
THE PROBLEM:
The kubeconfig file for PROD has "current-context" key available but the same is missing from the kubeconfig file for ITG.
prdconfig:
apiVersion: v1
clusters:
- cluster:
insecure-skip-tls-verify: true
server: https://cluster3.url.com:3600
name: cluster-ABC
contexts:
- context:
cluster: cluster-LMN
user: cluster-user
name: cluster-LMN-context
current-context: cluster-LMN-context
kind: Config
preferences: {}
users:
- name: cluster-user
user:
exec:
command: kubectl
apiVersion: <clientauth/version>
args:
- kubectl-custom-plugin
- authenticate
- https://cluster.url.com:8080
- --user=user
- --token=/api/v2/session/xxxx
- --token-expiry=1000000000
- --force-reauth=false
- --insecure-skip-tls-verify=true
itgconfig:
apiVersion: v1
clusters:
- cluster:
insecure-skip-tls-verify: true
server: https://cluster1.url.com:3600
name: cluster-ABC
- cluster:
insecure-skip-tls-verify: true
server: https://cluster2.url.com:3601
name: cluster-XYZ
contexts:
- context:
cluster: cluster-ABC
user: cluster-user
name: cluster-ABC-context
- context:
cluster: cluster-XYZ
user: cluster-user
name: cluster-XYZ-context
kind: Config
preferences: {}
users:
- name: cluster-user
user:
exec:
command: kubectl
apiVersion: <clientauth/version>
args:
- kubectl-custom-plugin
- authenticate
- https://cluster.url.com:8080
- --user=user
- --token=/api/v2/session/xxxx
- --token-expiry=1000000000
- --force-reauth=false
- --insecure-skip-tls-verify=true
When I try loading the kubeconfig file for PROD using config.load_kube_config(os.path.expanduser('~/.kube/prdconfig')) it works.
And when I try loading the kubeconfig file for ITG using config.load_kube_config(os.path.expanduser('~/.kube/itgconfig')), I get the following error:
ConfigException: Invalid kube-config file. Expected key
current-context in C:\Users<username>/.kube/itgconfig
Although it is very clear from the error message that it is considering the kubeconfig file as invalid, as it does not have "current-context" key in it.
THE SUB-PLOT:
When working with kubectl, the missing "current-context" does not make any difference as we can always specify context along with the command. But the 'load_kube_config()' function makes it mandatory to have "current-context" available.
THE QUESTION:
So, is "current-context" a mandatory key in kubeconfig file?
THE DISCLAIMER:
I am very new to kubernetes and have very little experience working with it.
As described in the comments:
If we want to use kubeconfig file to work out of the box by default, with specific cluster using kubectl or python script we can mark one of the contexts in our kubeconfig file as the default by specifying current-context.
Note about Context:
A context element in a kubeconfig file is used to group access parameters under a convenient name. Each context has three parameters: cluster, namespace, and user. By default, the kubectl command-line tool uses parameters from the current context to communicate with the cluster.
In order to mark one of our contexts (f.e. dev-fronted) in our kubeconfig file as the default one please run:
kubectl config use-context dev-fronted
Now whenever you run a kubectl command, the action will apply to the cluster, and namespace listed in the dev-frontend context. And the command will use the credentials of the user listed in the dev-frontend context
Please take a look at:
- Mering kubeconfig files:
determine the context to use based on the first hit in this chain:
Use the --context command-line flag if it exists.
Use the current-context from the merged kubeconfig files.
An empty context is allowed at this point.
determine the cluster and user. At this point, there might or might not be a context. Determine the cluster and user based on the first hit in this chain, which is run twice: once for user and once for cluster:
Use a command-line flag if it exists: --user or --cluster.
If the context is non-empty, take the user or cluster from the context.
The user and cluster can be empty at this point.
Whenever we run kubectl commands without specified current-context we should provide additional configuration parameters to tell kubectl which configuration to use, in your example it could be f.e.:
kubectl --kubeconfig=/your_directory/itgconfig get pods --context cluster-ABC-context
As described earlier - to simplify this task we can use configure current-context in kubeconfig file configuration:
kubectl config --kubeconfig=c/your_directory/itgconfig use-context cluster-ABC-context
Going further into errors generated by your script we should notice errors from config/kube_config.py:
config/kube_config.py", line 257, in set_active_context context_name = self._config['current-context']
kubernetes.config.config_exception.ConfigException:: Invalid kube-config file. Expected key current-context in ...
Here is an example with additional context="cluster-ABC-context" parameter:
from kubernetes import client, config
config.load_kube_config(config_file='/example/data/merged/itgconfig', context="cluster-ABC-context")
v1 = client.CoreV1Api()
print("Listing pods with their IPs:")
ret = v1.list_pod_for_all_namespaces(watch=False)
for i in ret.items:
print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
...
Listing pods with their IPs:
10.200.xxx.xxx kube-system coredns-558bd4d5db-qpzb8
192.168.xxx.xxx kube-system etcd-debian-test
...
Additional information
Configure Access to Multiple Clusters
Organizing Cluster Access Using kubeconfig Files
I need to use an environment variable inside my kubeconfig file to point the NODE_IP of the Kubernetes API server.
My config is:
apiVersion: v1
clusters:
- cluster:
insecure-skip-tls-verify: true
server: https://$NODE_IP:6443
name: docker-for-desktop-cluster
contexts:
- context:
cluster: docker-for-desktop-cluster
user: docker-for-desktop
name: docker-for-desktop
current-context: docker-for-desktop
kind: Config
preferences: {}
users:
- name: docker-for-desktop
user:
......
But it seems like the kubeconfig file is not getting rendered variables when I run the command:
kubectl --kubeconfig mykubeConfigFile get pods.
It complains as below:
Unable to connect to the server: dial tcp: lookup $NODE_IP: no such host
Did anyone try to do something like this or is it possible to make it work?
Thanks in advance
This thread contains explanations and answers:
... either wait Implement templates · Issue #23896 · kubernetes/kubernetes for the implementation of the templating proposal in k8s (not merged yet)
... or preprocess your yaml with tools like:
envsubst:
export NODE_IP="127.0.11.1"
envsubst < mykubeConfigFile.yml | kubectl --kubeconfig mykubeConfigFile.yml get pods
sed:
cat mykubeConfigFile.yml | sed s/\$\$EXTERNAL_IP/127.0.11.1/ | kubectl --kubeconfig mykubeConfigFile.yml get pods
I installed the puppet kubernetes module to manage pods of my kubernetes cluster with https://github.com/garethr/garethr-kubernetes/blob/master/README.md
I am not able to get any pod information back when I run
puppet resource kubernetes_pod
It just returns an empty line.
I am using a minikube k8s cluster to test the puppet module against.
cat /etc/puppetlabs/puppet/kubernetes.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority: /root/.minikube/ca.crt
server: https://<ip address>:8443
name: minikube
contexts:
- context:
cluster: minikube
user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
client-certificate: /root/.minikube/apiserver.crt
client-key: /root/.minikube/apiserver.key
I am able to use curl with the certs to talk to the K8s REST API
curl --cacert /root/.minikube/ca.crt --cert /root/.minikube/apiserver.crt --key /root/.minikube/apiserver.key https://<minikube ip>:844/api/v1/pods/
It looks like the garethr-kubernetes package hasn't been updated since August 2017, so you probably need a version of the kubeclient gem at least that old. It seems kubeclient 3.0 came out quite recently, so you might want to try the latest version from the 2.5 major (currently 2.5.2).
From the requirements, this could be related to a credentials issue.
Or the configuration is set to a namespace with nothing in it.
As show in this issue, check the following:
kubectl get pods works fine at the command line, and my ~/.puppetlabs/etc/puppet/kubernetes.conf file is generated as suggested:
mc0e#xxx:~$ kubectl config view --raw=true
apiVersion: v1
clusters:
- cluster:
server: http://localhost:8080
name: test-doc
contexts:
- context:
cluster: test-doc
user: ""
name: test-doc
current-context: test-doc
kind: Config
preferences: {}
users: []
I was trying out the Tectonic Kubernetes sandbox setup and according to their documentation:
https://coreos.com/tectonic/docs/latest/tutorials/first-app.html
I did download the kubectl and the corresponding kube-config files, but when I tried to get the namespaces using the following command:
kubectl get namespaces
I get the following error:
The connection to the server localhost:8080 was refused - did you specify the right host or port?
What is this? From where is it picking up this port locahost:8080?
EDIT:
Joe-MacBook-Pro:~ joe$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
Joe-MacBook-Pro:~ joe$
I'm lacking some details on your setup, but the problem is basically clear - you're not connected to the cluster.
You should have a kubeconfig file containing the cluster connection information i.e. the context, I assume if you run kubectl config view you'll get nothing.
I'm on windows using git bash, if I run the same command I get:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https://platform-svc-integration.net
name: svc-integration
contexts:
- context:
cluster: svc-integration
user: svc-integration-admin
name: svc-integration-system
current-context: svc-integration-system
kind: Config
preferences: {}
users:
- name: svc-integration-admin
user:
client-certificate: <path>/admin/admin.crt
client-key: <path>/admin/admin.key
basically what I'm trying to say is you need to configure your context, start by doing kubectl config --help to list your options, it's pretty straight forward but if don't manage just refer to the documentation.