I'm building a 3 VM (CentOS 7) cluster of Kubernetes 1.3.2.
According to this kubernetes documentation page Networking in Kubernetes: “We give every pod its own IP address” and by that there is no port collision when few pods use the same ports on the same node.
But as seen here, the pods do get the same IP addresses:
[root#gloom kuber-test]# kubectl get pods -o wide -l app=userloc
NAME READY STATUS RESTARTS AGE IP NODE
userloc-dep-857294609-0am9d 1/1 Running 0 27m 172.17.0.5 157.244.150.86
userloc-dep-857294609-a4538 1/1 Running 0 27m 172.17.0.7 157.244.150.96
userloc-dep-857294609-c4wzy 1/1 Running 0 6h 172.17.0.3 157.244.150.86
userloc-dep-857294609-hbl9i 1/1 Running 0 6h 172.17.0.5 157.244.150.96
userloc-dep-857294609-rpgyd 1/1 Running 0 27m 172.17.0.5 157.244.150.198
userloc-dep-857294609-tnnho 1/1 Running 0 6h 172.17.0.3 157.244.150.198
What do I miss?
EDIT - 31/07/16:
Following Sven Walter's comments, maybe the issue is that somehow the IPs which the pods had received are of the docker bridge subnet 172.17.0.0/16 (which is not distinct per node) instead of flannel’s subnets 10.x.x.x/24 (which are distinct per node).
Can this be the issue?
In case needed, here is the deployment yaml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: userloc-dep
spec:
replicas: 6
template:
metadata:
labels:
app: userloc
spec:
containers:
- name: userloc
image: globe:5000/openlso/userlocation-ms:0.1
ports:
- containerPort: 8081
The issue occured becuase following docker documentation I had added additional docker config in /etc/systemd/system/docker.service.d/docker.conf that overrides the config in /usr/lib/systemd/system/docker.service. Unfortunatelly the scripts I used to setup the cluster (master.sh and worker.sh) doesn't refer to the first file but to the second one.
Once I removed the docker.conf file the pods got flannel’s subnet.
After configuring flannel, assuming you did so correctly, each node will grab a slice of the overall ip network cidr. You can figure out which cidr is assigned to which node by doing an etcd ls -r and looking for a key like "coreos.com". The subnet slices assigned to each node should be unique.
Once a node has a subnet, flannel assigns that cidr to flannel.0 (a vxlan device) and you need to restart docker, eg: https://github.com/coreos/flannel#docker-integration. If you failed to restart docker, or the options are wrong, or flannel isn't running on the node, or non-unique subnets are assigned to different nodes, things won't work as expected. Reply to this if you need more help debugging and we can take it from there.
maybe it can help you, I have the same problem when I had more than one network interface to fix that I defined the network interface that flannel use to communicate with other nodes.
flanneld --iface=enp0s8
in my case, I change that in /etc/sysconfig/flanneld
FLANNEL_ETCD="http://master.gary.local:2379"
FLANNEL_ETCD_KEY="/atomic.io/network"
FLANNEL_OPTIONS="--iface=enp0s8"
after change that obviously you need to restart docker and flanneld daemons.
Related
I've deployed the redis helm chart on k8s with Sentinel enabled.
I've set up the Master-Replicas with Sentinel topology, it means one master and two slaves. Each pod is running both the redis and sentinel container successfully:
NAME READY STATUS RESTARTS AGE IP NODE
my-redis-pod-0 2/2 Running 0 5d22h 10.244.0.173 node-pool-u
my-redis-pod-1 2/2 Running 0 5d22h 10.244.1.96 node-pool-j
my-redis-pod-2 2/2 Running 0 3d23h 10.244.1.145 node-pool-e
Now, I've a python script that connects to redis and discovers the master by passing it the pod's ip.
sentinel = Sentinel([('10.244.0.173', 26379),
('10.244.1.96',26379),
('10.244.1.145',26379)],
sentinel_kwargs={'password': 'redispswd'})
host, port = sentinel.discover_master('mymaster')
redis_client = StrictRedis(
host=host,
port=port,
password='redispswd')
Let's suposse the master node is on my-redis-pod-0, when I do kubectl delete pod to simulate a problem that leads me to loss the pod, Sentinel will promote one of the others slaves to master and kubernetes will give me a new pod with redis and sentinel.
NAME READY STATUS RESTARTS AGE IP NODE
my-redis-pod-0 2/2 Running 0 3m 10.244.0.27 node-pool-u
my-redis-pod-1 2/2 Running 0 5d22h 10.244.1.96 node-pool-j
my-redis-pod-2 2/2 Running 0 3d23h 10.244.1.145 node-pool-e
The question is, how can I do to tell Sentinel to add this new ip to the list automatically (without code changes)?
Thanks!
Instead of using IPs, you may use the dns entries for a headless service.
A headless service is created by explicitly specifying
ClusterIP: None
Then you will be able to use the dns entries as under, where redis-0 will be the master
#syntax
pod_name.service_name.namespace.svc.cluster.local
#Example
redis-0.redis.redis.svc.cluster.local
redis-1.redis.redis.svc.cluster.local
redis-2.redis.redis.svc.cluster.local
References:
What is a headless service, what does it do/accomplish, and what are some legitimate use cases for it?
https://www.containiq.com/post/deploy-redis-cluster-on-kubernetes
I would like to know how exactly pods get an IP address, and how they distribute the pods to agent and master.
I have 1 master node and 2 agent nodes. my pods all are running well, but I am curious how the pods get an IP address.
some pods have IP cluster nodes, meanwhile, some have an ethernet IP address. I run Nginx and Metallb for the load balancer. Disable Traefik and Klipper.
if we can see the agent-03 has 2 IP addresses run on
root:/# kubectl get pods -A -o wide
ingress nginx-dep-fdcd8sdfs-gj5gff 1/1 Running 0 46h 10.42.0.80 master <none> <none>
ingress nginx-dep-fdcd8sdfs-dn80n 1/1 Running 0 46h 10.42.0.79 master <none> <none>
ingress nginx-doc-7cc85c5899-sdh55 1/1 Running 0 44h 10.42.0.82 master <none> <none>
ingress nginx-doc-7cc85c5899-gjghs 1/1 Running 0 44h 10.42.0.83 master <none> <none>
prometheus prometheus-node-exporter-6tl8t 1/1 Running 0 47h 192.168.1.3 agent-03 <none> <none>
ingress ingress-controller-nginx-ingress-controller-rqs8n 1/1 Running 5 47h 192.168.1.3 agent-03 <none> <none>
prometheus prometheus-kube-prometheus-operator-68fbcb6d67-8qsnf 1/1 Running 1 46h 10.42.2.52 agent-03 <none> <none>
ingress nginx-doc-7cc85c5899-b77j6 1/1 Running 0 43h 10.42.2.57 agent-03 <none> <none>
metallb-system speaker-sk4pz 1/1 Running 1 47h 192.168.1.3 agent-03 <none> <none>
in my pod's shows agent-03 run Nginx-doc use IP cluster while metal use IP ethernet, or it depends on what service are running in pods?
ingress nginx-doc-7cc85c5899-b77j6 1/1 Running 0 43h 10.42.2.57 agent-03 <none> <none>
metallb-system speaker-sk4pz 1/1 Running 1 47h 192.168.1.3 agent-03 <none> <none>
and I can see master has 2 Nginx-doc pods running, which means when I deploy 3 Nginx-doc one agent will not get any Nginx-doc because it has been taken by the master. and it is not divided equally.
If I miss configuring which part do I need to fix.
Based on your internal plugin your POD will get the IPs. Which again will be the internal IPs mostly.
There are different types of Network interfaces, we can use CNI as per need : https://kubernetes.io/docs/concepts/cluster-administration/networking/
POD gets exposed by the service. There are different types of services. Cluster IP, Node Port, Load Balancer. https://kubernetes.io/docs/concepts/services-networking/service/
in my pod's shows agent-03 run Nginx-doc use IP cluster while metal
use IP ethernet, or it depends on what service are running in pods?
Could be possible due to the service type you are using due to that IP is different and using ethernet.
If your service type is LoadBalancer using MetalLb which means that the service is exposed using the IP, not like internal IP that PODs have mostly.
kubectl get svc -n <namespace name> and check
and I can see master has 2 Nginx-doc pods running, which means when I
deploy 3 Nginx-doc one agent will not get any Nginx-doc because it has
been taken by the master. and it is not divided equally.
There is no guarantee on that, K8s put and assign pods based on score.
You can read more about score at here : https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
If you want to fix your POD on a specific node, suppose you are running the GPU with Node your should schedule on that Node to use GPU in that case you can use.
https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
Pod's IP address is provided by CNI driver from range that was specified when cluster was created using --pod-network-cidr, see here.
Some CNI implementations can implement additional behavior.
In your particular case I believe that pods in question are started using hostNetwork: true in their PodSpec, which gives them access to host network
*Cross-posted to k3d github discussions, to a thread in Rancher forums, and to traefik's community discussion board
Tutorials from 2020 refer to editing the traefik configmap. Where did it go?
The traefik installation instructions refer to a couple of ways to expose the dashboard:
This works, but isn't persistent: Using a 1-time command kubectl -n kube-system port-forward $(kubectl -n kube-system get pods --selector "app.kubernetes.io/name=traefik" --output=name) 9000:9000
I cannot get this to work: Creating an "IngressRoute" yaml file and applying it to the cluster. This might be due to the Klipper LB and/or my ignorance.
No configmap in use by traefik deployment
For a 2-server, 2-agent cluster... kubectl -n kube-system describe deploy traefik does not show any configmap:
Volumes:
data:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
tmp:
Type: EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit: <unset>
Priority Class Name: system-cluster-critical
No "traefik" configmap
And, kubectl get -n kube-system cm shows:
NAME DATA AGE
chart-content-traefik 0 28m
chart-content-traefik-crd 0 28m
chart-values-traefik 1 28m
chart-values-traefik-crd 0 28m
cluster-dns 2 28m
coredns 2 28m
extension-apiserver-authentication 6 28m
k3s 0 28m
k3s-etcd-snapshots 0 28m
kube-root-ca.crt 1 27m
local-path-config 4 28m
No configmap in use by traefik pods
Describing the pod doesn't turn up anything either. kubectl -n kube-system describe pod traefik-.... results in no configmap too.
Traefik ports in use, but not responding
However, I did see arguments to the traefik pod with ports in use:
--entryPoints.traefik.address=:9000/tcp
--entryPoints.web.address=:8000/tcp
--entryPoints.websecure.address=:8443/tcp
However, these ports are not exposed. So, I tried port-forward with kubectl port-forward pods/traefik-97b44b794-r9srz 9000:9000 8000:8000 8443:8443 -n kube-system --address 0.0.0.0, but when I curl -v localhost:9000 (or 8000 or 8443) and curl -v localhost:9000/dashboard, I get "404 Not Found".
After getting a terminal to traefik, I discovered the local ports that are open, but it seems nothing is responding:
/ $ netstat -lntu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 :::8443 :::* LISTEN
tcp 0 0 :::8000 :::* LISTEN
tcp 0 0 :::9000 :::* LISTEN
/ $ wget localhost:9000
Connecting to localhost:9000 ([::1]:9000)
wget: server returned error: HTTP/1.1 404 Not Found
/ $ wget localhost:8000
Connecting to localhost:8000 ([::1]:8000)
wget: server returned error: HTTP/1.1 404 Not Found
/ $ wget localhost:8443
Connecting to localhost:8443 ([::1]:8443)
wget: server returned error: HTTP/1.1 404 Not Found
Versions
k3d version v4.4.7
k3s version v1.21.2-k3s1 (default)
I found a solution and hopefully someone find a better one soon
you need to control your k3s cluster from your pc and not to ssh into master node, so add /etc/rancher/k3s/k3s.yaml into your local ~/.kube/config (in order to port forward in last step into your pc)
now get your pod name as follows:
kubectl get pod -n kube-system
and seach for traefik-something-somethingElse
mine was traefik-97b44b794-bsvjn
now this part is needed from your local pc
kubectl port-forward traefik-97b44b794-bsvjn -n kube-system 9000:9000
get http://localhost:9000/dashboard/ in your favorite browser and don't forget the second slash
enjoy the dashboard
please note you have to enable the dashboard first in /var/lib/rancher/k3s/server/manifests/traefik.yaml by adding
dashboard:
enabled: true
Jakub's answer is pretty good. But one thing that is unfortunate about it is that if k3s restarts, the configs get reset. According to the k3s docs, if you create a custom file called /var/lib/rancher/k3s/server/manifests/traefik-config.yaml, k3s' traefik will automatically update with this new config and use its values. Here is what I have:
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
dashboard:
enabled: true
ports:
traefik:
expose: true # this is not recommended in production deployments, but I want to be able to see my dashboard locally
logs:
access:
enabled: true
With this setup, you can skip the port-forwarding and just go to http://localhost:9000/dashboard/ directly!
for the current latest version of k3s (1.21.4):
according to traefik's installation guide (https://doc.traefik.io/traefik/getting-started/install-traefik/#exposing-the-traefik-dashboard), create dashboard.yaml with the proper CRD content, and run
kubectl apply -f dashboard.yaml
create DNS record or modify host file of the hostname - ip mapping for you set up in last step
I have a service running in a cluster in a namespace:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
amundsen-frontend LoadBalancer 10.100.59.220 a563823867e6f11ea82a90a9c116adac-124ae00284b50400.elb.us-west-2.amazonaws.com 80:31866/TCP 70m
And when I run pods:
kubectl get pods
NAME READY STATUS RESTARTS AGE
amundsen-frontend-595b49d856-mkbjj 1/1 Running 0 74m
amundsen-metadata-5df6c6c8d8-nrk9f 1/1 Running 0 74m
amundsen-search-c8b7cd9f6-mspzr 1/1 Running 0 74m
dsci-amundsen-elasticsearch-client-65f858c656-znjfd 1/1 Running 0 74m
dsci-amundsen-elasticsearch-data-0 1/1 Running 0 74m
dsci-amundsen-elasticsearch-master-0 1/1 Running 0 74m
I'm not really sure what to do here. How do I access the url? Can I port forward in development? What do I do in production? The front-end pod is one I want to access, so is the search pod.
This is what's in my charts.yaml for helm:
frontEnd:
##
## frontEnd.serviceName -- The frontend service name.
##
serviceName: frontend
##
## frontEnd.imageVersion -- The frontend version of the metadata container.
##
imageVersion: 2.0.0
##
## frontEnd.servicePort -- The port the frontend service will be exposed on via the loadbalancer.
##
servicePort: 80
With so little information I don't know if I can solve your problem, but will try to help you find it.
To start with it will be helpful if we can see your service and pod config?
kubectl get sa amundsen-frontend -o yaml
kubectl get pod amundsen-frontend-595b49d856-mkbjj -o yaml
You can try to reach the fronted from another pod, this will help figure out if the problem is in the pod or ingress layer.
To gain shell access inside search pod container run:
kubectl exec -it amundsen-search-c8b7cd9f6-mspzr --container <<name of container>> -- sh
If you have only one container in the pod you can omit the container part from the command above
Once inside check if your are able to reach amundsen-frontend-595b49d856-mkbjj with curl
curl amundsen-frontend-595b49d856-mkbjj
curl amundsen-frontend-595b49d856-mkbjj:31866
If you are able to establish communication, then look for the problem in the ingress layer. You may want to look at your ingress logs to see why it's timing out.
Network security groups in AWS as also worth exploring.
Is your ingress configured properly?
kubernetes v1.15.0 master is not able to reach pod ip address. I have been able to get it working till 1.14 but this time its not working any more. I have been using and setting up k8s clustors in ec2 using kubeadm.
Please find a log below; Any comments.
[ec2-user#ip-172-31-18-31 ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-172-31-16-120.ap-south-1.compute.internal Ready <none> 97m v1.15.0
ip-172-31-18-31.ap-south-1.compute.internal Ready master 116m v1.15.0
[ec2-user#ip-172-31-18-31 ~]$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hello-deploy-7fd5fc7ff-dh9pw 1/1 Running 0 6m32s 10.44.0.3 ip-172-31-16-120.ap-south-1.compute.internal <none> <none>
hello-deploy-7fd5fc7ff-vrxbd 1/1 Running 0 6m32s 10.44.0.4 ip-172-31-16-120.ap-south-1.compute.internal <none> <none>
hello-pod1 1/1 Running 0 22m 10.44.0.1 ip-172-31-16-120.ap-south-1.compute.internal <none> <none>
[ec2-user#ip-172-31-18-31 ~]$ hostname
ip-172-31-18-31.ap-south-1.compute.internal
[ec2-user#ip-172-31-18-31 ~]$ curl http://10.44.0.4
Just simply create service for your pod to access it within the cluster, type of service should be ClusterIP.
Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a type in the ServiceSpec.
ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluste
Egg.:
apiVersion: v1
kind: Service
metadata:
name: test-service
spec:
selector:
app: test
Remember to match selector of service to pod's selector.