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?
4 Answers
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!
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?
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.
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.
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!
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.