CODEWITHSUNDEEP
kubernetes
Richard Rublev
Richard Rublev

Reputation: 8160

Kubernetes:why my deployment lacks endpoint?

I am leaning Kubernetes,have applied secrets to my previously running deployments. Now, I have problem that I can not run my site

kubectl get ep -o wide
NAME                ENDPOINTS                                                      AGE
hello-node          172.17.0.8:8080                                                2d21h
kubernetes          192.168.99.101:8443                                            3d
tomcat-deployment   172.17.0.10:8080,172.17.0.6:8080,172.17.0.7:8080 + 1 more...   2d16h
wordpress                                                                          24h
wordpress-mysql     172.17.0.15:3306                                               24h

Describe output

Name:               wordpress
Namespace:          default
CreationTimestamp:  Tue, 12 Mar 2019 09:10:24 +0100
Labels:             app=wordpress
Annotations:        deployment.kubernetes.io/revision: 1
                    kubectl.kubernetes.io/last-applied-configuration:
                      {"apiVersion":"apps/v1beta2","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"wordpress"},"name":"wordpress","namespace":...
Selector:           app=wordpress,tier=frontend
Replicas:           1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType:       Recreate
MinReadySeconds:    0
Pod Template:
  Labels:  app=wordpress
           tier=frontend
  Containers:
   wordpress:
    Image:      wordpress:4.8-apache
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:
      WORDPRESS_DB_HOST:      wordpress-mysql
      WORDPRESS_DB_PASSWORD:  <set to the key 'password' in secret 'mysql-pass'>  Optional: false
    Mounts:
      /var/www/html from wordpress-persistent-storage (rw)
  Volumes:
   wordpress-persistent-storage:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  wp-pv-claim
    ReadOnly:   false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      False   MinimumReplicasUnavailable
OldReplicaSets:  <none>
NewReplicaSet:   wordpress-dccb8668f (1/1 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  7m37s  deployment-controller  Scaled up replica set wordpress-dccb8668f to 1

I deleted previous deployment and have created the new one because some problems occur while running secrets cli. I do not understand this, why is end point missing? It also shows that my replica is unavailable,how to fix this? I created deployment with

apply -f ./deployment.yaml

Pods are running

wordpress-dccb8668f-4j6wg            1/1     Running            29         137m
wordpress-mysql-7d4fc77fdc-fmhdh     1/1     Running            0          141m

get svc -o wide

wordpress           LoadBalancer   10.102.29.45     <pending>     80:31262/TCP     26h     app=wordpress,tier=frontend
wordpress-mysql     ClusterIP      None             <none>        3306/TCP         26h     app=wordpress,tier=mysql

EDIT I changed deployment.yaml as suggested by S.Schenkel

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: NodePort

I still have the same problem.

minikube service wordpress --url
http://192.168.99.101:31262
miki@miki:~$ curl http://192.168.99.101:31262
curl: (7) Failed to connect to 192.168.99.101 port 31262: Connection refused
miki@miki:~$

If someone wants to reproduce the example

https://github.com/LevelUpEducation/kubernetes-demo/tree/master/Advanced%20Kubernetes%20Usage/Secrets

NAME                TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE     SELECTOR
hello-node          LoadBalancer   10.104.141.138   <pending>     8080:31321/TCP   3d3h    app=hello-node
kubernetes          ClusterIP      10.96.0.1        <none>        443/TCP          3d6h    <none>
tomcat-deployment   LoadBalancer   10.107.218.19    <pending>     8080:32688/TCP   2d22h   app=tomcat
wordpress           NodePort       10.102.29.45     <none>        80:31262/TCP     30h     app=wordpress,tier=frontend
wordpress-mysql     ClusterIP      None             <none>        3306/TCP         30h     app=wordpress,tier=mysql

Pods

wordpress-dccb8668f-gk2hn            0/1     CrashLoopBackOff   27         126m    172.17.0.8    minikube   <none>           <none>
wordpress-mysql-7d4fc77fdc-fmhdh     1/1     Running            1          6h23m   172.17.0.19   minikube   <none>           <none>

CrashLoopBackOff means what?

Upvotes: 0

Views: 645

Answers (3)

A_Suh
A_Suh

Reputation: 3956

I've just reproduced your case within the minikube and was able to reach the wordpress service

Here is step-by-step instruction:

  1. Create a secret for MySQL deployment

kubectl create secret generic mysql-pass --from-literal=password=password

  1. Deploy MySQL first.
  2. Deploy wordpress
  3. Edit wordpress service type from type: LoadBalancer to type: NodePort

kubectl edit svc wordpress

  1. Make sure that all pods are running

kubectl get pods -o wide

  1. If no issue with pods, try to curl the service

curl -v $(minikube service --url wordpress)

You should have something like this

sukhoversha@minikube:~$ curl -v $(minikube service --url wordpress)
* Rebuilt URL to: http://192.168.99.100:32144/
*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 32144 (#0)
> GET / HTTP/1.1
> Host: 192.168.99.100:32144
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Tue, 12 Mar 2019 15:26:23 GMT
< Server: Apache/2.4.10 (Debian)
< X-Powered-By: PHP/5.6.32
< Expires: Wed, 11 Jan 1984 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate, max-age=0
< Location: http://192.168.99.100:32144/wp-admin/install.php
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
< 
* Connection #0 to host 192.168.99.100 left intact

Upvotes: 2

S. Schenkel
S. Schenkel

Reputation: 191

I see you are using LoadBalancer type for your service wordpress. Are you using kubernetes on a cloud solution ? (like google cloud) Or are you using on-premise solution (with kubeadm or minikube) ? If it is on-premise you can't use LoadBalancer service type because this type uses external Load Balancer solution (for google cloud or amazon aws) You need to use ExternalIPs or NodePort.

Upvotes: 1

Akash Sharma
Akash Sharma

Reputation: 757

Check the service selector and POD labels. Service points to PODs based on labels defined in selector.

Upvotes: -1

Related Questions