I am trying install flannel on master node and getting below error.
unable to recognize "https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml": no matches for kind "DaemonSet" in version "extensions/v1beta1"
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
Conf file:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
networking:
podSubnet: 10.244.0.0/16
apiServerExtraArgs:
service-node-port-range: 8000-31274
~
You must be using Kubernetes version >=1.16. DaemonSet in extensions/v1beta1 is deprecated..
Use apps/v1 api group instead.
Try using https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml.
Related
I am trying to install a calico GlobalNetworkPolicy that will be applicable to all the pods in the cluster regardless of namespace , and to apply GlobalNetworkPolicy as per docs here -
Calico network policies and Calico global network policies are applied
using calicoctl
i.e calicoctl command (assuming calicoctl binary installed in the host) ->
calicoctl apply -f global-policy.yaml
OR if we have a calicoctl pod running ->
kubectl exec -ti -n kube-system calicoctl -- /calicoctl apply -f global-deny.yaml -o wide
global-policy.yaml ->
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: default-deny
spec:
selector: projectcalico.org/namespace == "kube-system"
types:
- Ingress
- Egress
Question -> How do I install such a policy via helm chart ? As helm implicitly calls via kubectl and that causes error on install.
Error using kubectl or helm =>
Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: resource mapping not found for name: "default-deny" namespace: "" from "": no matches for kind "GlobalNetworkPolicy" in version "projectcalico.org/v3"
As per the Doc given by you Calico global network policy is a non-namespaced resource and can be applied to any kind of endpoint (pods, VMs, host interfaces) independent of namespace.
But you are using namespace in the Yaml, that might be the reason for the error. Kindly remove the name space and try again.
Because global network policies use kind: GlobalNetworkPolicy, they are grouped separately from kind: NetworkPolicy. For example, global network policies will not be returned from calicoctl get networkpolicy, and are rather returned from calicoctl get globalnetworkpolicy.
Below is the reference yaml from Doc :
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: allow-tcp-port-6379
Refer For more information on Global Network Policy, Calico Install Via Helm and Calico command line tools.
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
By using kubectl get networkpolicy, I can see only the policies created by networking.k8s.io/v1 and not those created by projectcalico.org/v3. Any suggestion how to see the latter ones?
kubectl get XXX does not display all the resources in the cluster, in your case you cannot see CRD
You can find your object with kubectl get crds
Then kubectl get <crd name> -A
In your case it would be:
# Get all the CRD from the desired type
kubectl get projectcalico.org/v3 -A
# Now grab the desired name and do whatever you want with it
kubectl describe <CRD>/<resource name> -n <namespace>
I am following a MongoDB tutorial on Kubernetes, but when I create the configuration map, it gives me this error:
error: unable to recognize "mongo-configmap.yaml": no matches for kind "ConfigMap" in version "V1"
This is the mongo-configmap.yaml file:
apiVersion: V1
kind: ConfigMap
metadata:
name: mongodb-configmap
data:
database_url: mongodb-service
The version should be lower case.
apiVersion: v1
lang-none
You can run the below command to refer to the attributes.
kubectl explain cm | head
Or
kubectl explain cm --recursive | grep -i <attribute> or head
KIND: ConfigMap
VERSION: v1
DESCRIPTION:
ConfigMap holds configuration data for pods to consume.
FIELDS:
apiVersion <string>
binaryData <map[string]string>
data <map[string]string>
I have a question about the usage of apiVersion in Kuberntes.
For example I am trying to deploy traefik 2.2.1 into my kubernetes cluster. I have a traefik middleware deployment definition like this:
---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: https-redirect
spec:
redirectScheme:
scheme: https
permanent: true
port: 443
When I try to deploy my objects with
$ kubectl apply -f middleware.yaml
I got the following error message:
unable to recognize "middleware.yaml": no matches for kind "Middleware" in version "traefik.containo.us/v1alpha1"
The same object works fine with Traefik version 2.2.0 but not with version 2.2.1.
On the traefik documentation there is no example other the ones using the version "traefik.containo.us/v1alpha1"
I dont't hink that my deployment issue is specific to traefik. It is a general problem with conflicting versions. Is there any way how I can figure out which apiVersions are supported in my cluster environment?
There are so many outdated examples posted around using deprecated apiVersions that I wonder if there is some kind of official apiVersion directory for kubernetes? Or maybe there is some kubectl command which I can ask for apiversions?
Most probably crds for traefik v2 are not installed. You could use below command which lists the API versions that are available on the Kubernetes cluster.
kubectl api-versions | grep traefik
traefik.containo.us/v1alpha1
Use below command to check crds installed on the Kubernetes cluster.
kubectl get crds
NAME CREATED AT
ingressroutes.traefik.containo.us 2020-05-09T13:58:09Z
ingressroutetcps.traefik.containo.us 2020-05-09T13:58:09Z
ingressrouteudps.traefik.containo.us 2020-05-09T13:58:09Z
middlewares.traefik.containo.us 2020-05-09T13:58:09Z
tlsoptions.traefik.containo.us 2020-05-09T13:58:09Z
tlsstores.traefik.containo.us 2020-05-09T13:58:09Z
traefikservices.traefik.containo.us 2020-05-09T13:58:09Z
Check traefik v1 vs v2 here
I found that if I just run the kubectl apply again after a few moments it will then work.
New cluster 1.8.10 spinned with kops.
In K8S 1.8 there is a new feature Pod Priority and Preemption.
More information: https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#how-to-use-priority-and-preemption
kube-apiserver is logging errors
I0321 16:27:50.922589 7 wrap.go:42] GET
/apis/admissionregistration.k8s.io/v1alpha1/initializerconfigurations:
(140.067µs) 404 [[kube-apiserver/v1.8.10 (linux/amd64)
kubernetes/044cd26] 127.0.0.1:47500] I0321 16:27:51.257756 7
wrap.go:42] GET
/apis/scheduling.k8s.io/v1alpha1/priorityclasses?resourceVersion=0:
(168.391µs) 404 [[kube-apiserver/v1.8.10 (linux/amd64)
kubernetes/044cd26] 127.0.0.1:47500] E0321 16:27:51.258176 7
reflector.go:205]
k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:73:
Failed to list *scheduling.PriorityClass: the server could not find
the requested resource (get priorityclasses.scheduling.k8s.io)
I quite not understand why. No one should access it as it's not even enabled yet (it's alpha).
No pod is using priorityClassName.
Running explain:
kubectl explain priorityclass error: API version:
scheduling.k8s.io/v1alpha1 is not supported by the server. Use one of:
[apiregistration.k8s.io/v1beta1 extensions/v1beta1 apps/v1beta1
apps/v1beta2 authentication.k8s.io/v1
authentication.k8s.io/v1beta1 authorization.k8s.io/v1
authorization.k8s.io/v1beta1 autoscaling/v1 autoscaling/v2beta1
batch/v1 batch/v1beta1 certificates.k8s.io/v1beta1
networking.k8s.io/v1 policy/ v1beta1
rbac.authorization.k8s.io/v1 rbac.authorization.k8s.io/v1beta1
storage.k8s.io/v1 storage.k8s.io/v1beta1 apiextensions.k8s.io/v1beta1
v1]
Is this normal or kops specific?
I think it is related to that Kops option in its config (kops get --name $NAME -oyaml):
kubeAPIServer:
runtimeConfig:
admissionregistration.k8s.io/v1alpha1: "true"
Anyway, all components working thru the API server and it is not a surprise that sometimes based on configuration it is trying to call some disable features. At least it has to check which APIs a supported, so why :)
So, I think you don't need to worry about it, that is the configuration-related message. Don't worry about it. Or just enable that feature, it will solve warning messages.