NodePort Not Registering Endpoints for My Minecraft Server Pod

July 21, 2025 4 answers
Asked by GamerDude2023
Hey everyone! I'm trying to set up a Minecraft server using a StatefulSet configuration that I've used successfully before. I configured the readiness and liveness probes to run `/usr/bin/true` just to force it into a ready state. However, even though the init container completes and the Minecraft server starts fine, the NodePort service isn't registering any endpoints. Here's what my StatefulSet and NodePort service YAML look like: **StatefulSet YAML:** ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: minecraft labels: app: minecraft spec: replicas: 1 selector: matchLabels: app: minecraft template: metadata: labels: app: minecraft spec: initContainers: - name: copy-configs image: alpine:latest restartPolicy: Always command: - /bin/sh - -c - "apk add rsync && rsync -auvv --update /configs /data || /bin/true" volumeMounts: - mountPath: /configs name: config-vol - mountPath: /data name: data containers: - name: minecraft image: itzg/minecraft-server ports: - containerPort: 80 envFrom: - configMapRef: name: deploy-config volumeMounts: - mountPath: /data name: data readinessProbe: exec: command: - /usr/bin/true initialDelaySeconds: 30 periodSeconds: 10 livenessProbe: exec: command: - /usr/bin/true initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 5 resources: limits: cpu: 4000m memory: 4096Mi requests: cpu: 50m memory: 1024Mi dnsPolicy: ClusterFirst restartPolicy: Always volumes: - name: config-vol configMap: name: configs - name: data nfs: server: 192.168.11.69 path: /mnt/user/kube-nfs/minecraft readOnly: false ``` **NodePort Service YAML:** ```yaml apiVersion: v1 kind: Service metadata: labels: app: minecraft name: minecraft spec: ports: - name: 25565-31565 port: 25565 protocol: TCP nodePort: 31565 selector: app: minecraft type: NodePort status: loadBalancer: {} ``` Even after the server starts, when I check the services and endpoints, I see no endpoints registered: ```bash $ kubectl get services -n vault-hunter-minecraft NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE minecraft NodePort 10.152.183.51 25565:31566/TCP 118s $ kubectl get endpoints -n vault-hunter-minecraft NAME ENDPOINTS AGE minecraft 184s $ kubectl get all -n vault-hunter-minecraft NAME READY STATUS RESTARTS AGE pod/minecraft-0 1/2 Running 5 4m43s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/minecraft NodePort 10.152.183.51 25565:31566/TCP 4m43s NAME READY AGE statefulset.apps/minecraft 0/1 4m43s ``` I suspect that the readiness state is blocking the service from registering the endpoint. Any thoughts or suggestions to fix this?

Answers

KubeMaster88
Make sure your StatefulSet isnโ€™t constantly restarting; otherwise, the service wonโ€™t find an endpoint to connect to. Check the events and logs to isolate if any pods are failing. This often causes the NodePort service to have no endpoints registered. Also, when `kubectl get all` shows `1/2`, that indicates one container is running, while the other isnโ€™t. You need to check whatโ€™s happening with the other one!
Reply to this answer
DevDanny91
Just a heads-up, your inline code blocks aren't showing up properly in mobile apps due to the use of triple backticks. They recommend using indentation instead for formatting. That might make your post clearer to others. Also, could you share outputs from `kubectl describe sts` or `kubectl describe pod`? That could uncover more details about whatโ€™s going wrong with your setup.

GamerDude2023: Thanks for the formatting tip! Iโ€™ll keep that in mind next time. As for the commands, I found the problem was with the `restartPolicy: Always` causing continuous restarts.

Reply to this answer
TechieTina77
It looks like you're using both liveness and readiness probes that are effectively always returning true with `/usr/bin/true`. If the idea was just to bypass checks, it's probably unnecessary to have those probes in there at all. Maybe simplify them to help debug your issue?

User1234: Yeah, I wondered about that too! If your probes donโ€™t actually check anything meaningful, it could lead to confusion about the pod's readiness.

Reply to this answer
CloudGuru15
The problem with the endpoint not registering can be tricky. If your init container has a restart policy thatโ€™s too aggressive, it might interfere with your main application becoming ready. If you can, start by removing that and see if it helps!
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions