I have just installed a basic kubernetes cluster the manual way, to better understand the components, and to later automate this installation. I followed this guide: https://kubernetes.io/docs/getting-started-guides/centos/centos_manual_config/
The cluster is completely empty without addons after this. I've already deployed kubernetes-dashboard succesfully, however, when trying to deploy kube-dns, it fails with the log:
2017-01-11T15:09:35.982973000Z F0111 15:09:35.978104 1 server.go:55]
Failed to create a kubernetes client:
invalid configuration: no configuration has been provided
I used the following yaml template for kube-dns without modification, only filling in the cluster IP:
https://coreos.com/kubernetes/docs/latest/deploy-addons.html
What did I do wrong?
Experimenting with kubedns arguments, I added --kube-master-url=http://mykubemaster.mydomain:8080 to the yaml file, and suddenly it reported in green.
How did this solve it? Was the container not aware of the master for some reason?
In my case, I had to put numeric IP on "--kube-master-url=http://X.X.X.X:8080". It's on yaml file of RC (ReplicationController), just like:
...
spec:
containers:
- name: kubedns
...
args:
# command = "/kube-dns"
- --domain=cluster.local
- --dns-port=10053
- --kube-master-url=http://192.168.99.100:8080
Related
We are running an application inside a cluster we created in GKE. We have created required yamls (consisting of Service and Deployment definition). We recently have decided to use Pod Topology for that I have added following piece in my Deployment yaml file under spec section-
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: node
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: foo-app
This change is working as expected when I am running the service inside a minikube cluster while the same change is not working inside a GKE cluster. It throws an error-
Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(Deployment.spec.template.spec): unknown field "topologySpreadConstraints" in io.k8s.api.core.v1.PodSpec
I searched a lot but could not find a satisfactory answer. Has anybody faced this problem? Please help me understand the problem and its resolution.
Thanks in Advance.
I assume you are running 1.17.7-gke.17 on your GKE cluster. Unfortunately this is the latest version you can upgrade to, through the rapid channel, at the time of this post.
topologySpreadConstraints is available in Kubernetes v1.18 FEATURE STATE: [beta]
I have tried to deploy one of the local container images I created but keeps always getting the below error
Failed to pull image "webrole1:dev": rpc error: code = Unknown desc =
Error response from daemon: pull access denied for webrole1,
repository does not exist or may require 'docker login': denied:
requested access to
I have followed the below article to containerize my application and I was able to successfully complete this but when I try to deploy it to k8s pod I don't succeed
My pod.yaml looks like below
apiVersion: v1
kind: Pod
metadata:
name: learnk8s
spec:
containers:
- name: webrole1dev
image: 'webrole1:dev'
ports:
- containerPort: 8080
and below are some images from my PowerShell
I am new to dockers and k8s so thanks for the help in advance and would appreciate if I get some detailed response.
When you're working locally, you can use an image name like webrole, however that doesn't tell Docker where the image came from (because it didn't come from anywhere, you built it locally). When you start working with multiple hosts, you need to push things to a Docker registry. For local Kubernetes experiments you can also change your config so you build your image in the same Docker environment as Kubernetes is using, though the specifics of that depend on how you set up both Docker and Kubernetes.
I have a kubernetes cluster set up and I would like to use local images. I have configured .yaml file so that it contains (in containers -> image -section) "imagePullPolicy: Never" like this:
spec:
containers:
- image: <name>:<version>
name: <name>
imagePullPolicy: Never
resources: {}
restartPolicy: Always
I have deployed this service to kubernetes but image cannot be pulled (getting ImagePullBackOff -error when viewing pods with kubectl get pod) since image cannot be found from internet/registry and for some unknown reason imagePullPolicy is in Always-value. This can be seen e.g. from /var/log/messages from text:
"spec":{"containers":[{"image":"<name>","imagePullPolicy":"Always","name":"<name>","
So my question is: Why is this imagePullPolicy in Always-value though I have set imagePullPolicy to Never in my .yaml file (which has of course been taken into use)? Is there some default value for imagePullPolicy that runs over the value described in .yaml file?
My environment is Centos7 and I'm using Kontena Pharos 2.2.0 (uses e.g. docker 1.13.1 (Apache License 2.0) and kubernetes 1.13.2 (Apache License 2.0)).
I expected that when I set "imagePullPolicy: Never" in .yaml file the value should now be Never (and not Always).
Thank you so much for helping!
welcome on StackOverflow.
It happens so, because your Kubernetes cluster has presumably enabled admission control plugin in api server, called 'AlwaysPullImages', which role is to overwrite (mutate) objects prior storing them in Kubernetes data store - etcd.
This is a default behavior of clusters bootstrapped with Kontena Pharos since version v2.0.0-alpha.2.
You can disable this admission plugin in your main cluster.yml config file:
...
addons:
ingress-nginx:
enabled: true
admission_plugins:
- name: AlwaysPullImages
enabled: false
...
You should expect then to see PODs failing with different status reason, if image is not found on local registry:
client-deployment-99699599d-lfqmr 0/1 ErrImageNeverPull 0 42s
Please read more on using of Admission Controllers here
I am following the Getting Started guide for Traefik from here and am trying to launch the service into Kubernetes (Minikube) instead of Docker:
Edit your docker-compose.yml file and add the following at the end of your file.
# ...
whoami:
image: emilevauge/whoami # A container that exposes an API to show its IP address
labels:
- "traefik.frontend.rule=Host:whoami.docker.localhost"**
I am guessing I run it as:
kubectl run whoami-service --image=emilevauge/whoami --labels='traefik.frontend.rule=Host:whoami.docker.localhost'
however that generates an error of:
The Deployment "whoami-service" is invalid:
* metadata.labels: Invalid value: "'traefik.frontend.rule": name part must consist of alphanumeric characters, '-', '_' or '.', and....
So what am I missing here? How do I deploy the above to my Minikube Kubernetes cluster?
I'm not sure if this is along the lines of what you're looking for, but Traefik has a small tutorial for getting an Ingress controller set up on Kubernetes, with a great document on configuration, as well.
If you'd just like to get that particular image working, you may be able to pass the label as an argument to the pod, possibly with kubectl run. From the output of kubectl run help:
# Start the nginx container using the default command, but use custom arguments (arg1 .. argN) for that command.
kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>
Or possibly manually in a manifest:
...
containers:
- name: whoami
image: emilevauge/whoami
args: ["traefik.frontend.rule: "Host:whoami.docker.localhost"]
Having never worked with the image in the example before, I don't know if either the above examples will actually work.
Hope that helps a little!
I am new to kubernetes and docker. I am trying to chain 2 containers in a pod such that the second container should not be up until the first one is running. I searched and got a solution here. It says to add "depends" field in YAML file for the container which is dependent on another container. Following is a sample of my YAML file:
apiVersion: v1beta4
kind: Pod
metadata:
name: test
labels:
apps: test
spec:
containers:
- name: container1
image: <image-name>
ports:
- containerPort: 8080
hostPort: 8080
- name: container2
image: <image-name>
depends: ["container1"]
Kubernetes gives me following error after running the above yaml file:
Error from server (BadRequest): error when creating "new.yaml": Pod in version "v1beta4" cannot be handled as a Pod: no kind "Pod" is registered for version "v1beta4"
Is the apiVersion problem here? I even tried v1, apps/v1, extensions/v1 but got following errors (respectively):
error: error validating "new.yaml": error validating data: ValidationError(Pod.spec.containers[1]): unknown field "depends" in io.k8s.api.core.v1.Container; if you choose to ignore these errors, turn validation off with --validate=false
error: unable to recognize "new.yaml": no matches for apps/, Kind=Pod
error: unable to recognize "new.yaml": no matches for extensions/, Kind=Pod
What am I doing wrong here?
As I understand there is no field called depends in the Pod Specification.
You can verify and validate by following command:
kubectl explain pod.spec --recursive
I have attached a link to understand the structure of the k8s resources.
kubectl-explain
There is no property "depends" in the Container API object.
You split your containers in two different pods and let the kubernetes cli wait for the first container to become available:
kubectl create -f container1.yaml --wait # run command until the pod is available.
kubectl create -f container2.yaml --wait