2

I was trying out spring boot microservice deployment on kubernetes cluster using Helm Chart. But I noticed a strange issue that my spring boot application start but it shutdown immediately after

Here are the logs

Started JhooqK8sApplication in 3.431 seconds (JVM running for 4.149)
2020-06-25 20:57:24.460  INFO 1 --- [extShutdownHook] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'
2020-06-25 20:57:24.469  INFO 1 --- [extShutdownHook] o.e.jetty.server.AbstractConnector       : Stopped ServerConnector@548a102f{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2020-06-25 20:57:24.470  INFO 1 --- [extShutdownHook] org.eclipse.jetty.server.session         : node0 Stopped scavenging
2020-06-25 20:57:24.474  INFO 1 --- [extShutdownHook] o.e.j.s.h.ContextHandler.application     : Destroying Spring FrameworkServlet 'dispatcherServlet'
2020-06-25 20:57:24.493  INFO 1 --- [extShutdownHook] o.e.jetty.server.handler.ContextHandler  : Stopped o.s.b.w.e.j.JettyEmbeddedWebAppContext@56528192{application,/,[file:///tmp/jetty-docbase.4637295322181051129.8080/],UNAVAILABLE}

Spring Boot Version : 2.2.7.RELEASE Docker Hub Public image for spring boot : rahulwagh17/kubernetes:jhooq-k8s-springboot-jetty

One strange thing which i noticed when i use kubectl command manually to create deployment and service spring boot deployments goes perfectly fine.

vagrant@kmaster:~$ kubectl create deployment demo --image=rahulwagh17/kubernetes:jhooq-k8s-springboot-jetty

vagrant@kmaster:~$ kubectl expose deployment demo --type=LoadBalancer --name=demo-service --external-ip=1.1.1.1 --port=8080

(I followed this guide for deploying spring boot on kubernete - Deploy spring boot on kubernetes cluster)

I am just wodering is there something wrong with spring boot or my helm setup?

Here is my helm templates -

---
# Source: springboot/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: RELEASE-NAME-springboot
  labels:
    helm.sh/chart: springboot-0.1.0
    app.kubernetes.io/name: springboot
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
---
# Source: springboot/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: RELEASE-NAME-springboot
  labels:
    helm.sh/chart: springboot-0.1.0
    app.kubernetes.io/name: springboot
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: springboot
    app.kubernetes.io/instance: RELEASE-NAME
---
# Source: springboot/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: RELEASE-NAME-springboot
  labels:
    helm.sh/chart: springboot-0.1.0
    app.kubernetes.io/name: springboot
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: springboot
      app.kubernetes.io/instance: RELEASE-NAME
  template:
    metadata:
      labels:
        app.kubernetes.io/name: springboot
        app.kubernetes.io/instance: RELEASE-NAME
    spec:
      serviceAccountName: RELEASE-NAME-springboot
      securityContext:
        {}
      containers:
        - name: springboot
          securityContext:
            {}
          image: "rahulwagh17/kubernetes:jhooq-k8s-springboot-jetty"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}
---
# Source: springboot/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "RELEASE-NAME-springboot-test-connection"
  labels:
    helm.sh/chart: springboot-0.1.0
    app.kubernetes.io/name: springboot
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test-success
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['RELEASE-NAME-springboot:80']
  restartPolicy: Never

Rahul Wagh
  • 470
  • 1
  • 6
  • 23

1 Answers1

2

2020-06-25 20:57:24.469 INFO 1 --- [extShutdownHook] o.e.jetty.server.AbstractConnector : Stopped ServerConnector@548a102f{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}

         ports:
           - name: http
             containerPort: 80

It appears the liveness probe (configured to contact the port named http) is killing your Pod since your container appears to be listening on :8080 but you've told kubernetes that it's listening on :80

Since a kubectl created deployment will not have any such specificity, kubernetes won't use a liveness probe and there you are

You can usually configure the spring application via an environment variable if you want to test that theory:

      containers:
        - name: springboot
          env:
          - name: SERVER_PORT
            value: '80'
          # and its friend, which is the one that 
          # you should be using for liveness and readiness
          - name: MANAGEMENT_SERVER_PORT
            value: '8080'
          securityContext:
            {}
          image: "rahulwagh17/kubernetes:jhooq-k8s-springboot-jetty"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
mdaniel
  • 31,240
  • 5
  • 55
  • 58
  • Thanks @mdaniel for the suggestion. After reading your comment i realized that i didn't enabled the health endpoints for my spring boot application, so when kubernetes trying to check the readiness and livelyness of the application it might be getting the 404. But i will first enable the health endpoint and then try out the helm install again. – Rahul Wagh Jun 26 '20 at 09:28