Kubernetes on Jiale's personal blog

知识点：helm

Thu, 21 May 2026 20:34:27 +0800

helm install之后的log be like：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


(base) savilahao@bogon ~ % helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring --create-namespace
NAME: prometheus
LAST DEPLOYED: Wed May 20 14:54:39 2026
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
kube-prometheus-stack has been installed. Check its status by running:
  kubectl --namespace monitoring get pods -l "release=prometheus"
  # ======================Grafana登陆与port转发教程===============
Get Grafana 'admin' user password by running:

  kubectl --namespace monitoring get secrets prometheus-grafana -o jsonpath="{.data.admin-password}" | base64 -d ; echo

Access Grafana local instance:
  export POD_NAME=$(kubectl --namespace monitoring get pod -l "app.kubernetes.io/name=grafana,app.kubernetes.io/instance=prometheus" -oname)

  kubectl --namespace monitoring port-forward $POD_NAME 3000

Get your grafana admin user password by running:

 
  kubectl get secret --namespace monitoring -l app.kubernetes.io/component=admin-secret -o jsonpath="{.items[0].data.admin-password}" | base64 --decode ; echo


Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.

如helm创建后指导所示看密码： kubectl get secret --namespace monitoring -l app.kubernetes.io/component=admin-secret -o jsonpath="{.items[0].data.admin-password}" | base64 --decode ; echo ^ebfc61

查看helm起的agons的配置：

helm list -A看release名：

1
2
3
4


NAME 	NAMESPACE 	REVISION	UPDATED 	STATUS 	CHART 	APP VERSION
agones 	agones-system 	1 	2026-05-19 13:07:59.439179 +0800 CST	deployed	agones-1.57.0 	1.57.0
metallb 	metallb-system	1 	2026-05-19 13:01:18.107293 +0800 CST	deployed	metallb-0.15.3 	v0.15.3
prometheus	monitoring 	1 	2026-05-20 14:54:39.049677 +0800 CST	deployed	kube-prometheus-stack-85.2.0	v0.90.1

看具体配置（也就是value

[!注意默认不加“a参数” 的话只能看到你手动set过的value] helm get values agones -n agones-system -a

1
2
3


(base) savilahao@bogon ~ % helm get values agones -n agones-system -a | grep prome
 prometheusEnabled: true
 prometheusServiceDiscovery: true

Q1:prometheusEnabled: true说明什么？在 Agones 中开启这个配置，它的实际意思是：Agones Controller 在代码层面启动了一个内置的 HTTP Server（通常是 8080 端口的 /metrics 路径），并且开始以 Prometheus 能看懂的纯文本格式往外“吐”数据（比如当前有多少个游戏服）。 Q2:prometheusServiceDiscovery: true 是干嘛的？简答：做服务发现—— 原生 Kubernetes 早期是用 Annotations（注解）来做服务发现的。开启这个，Agones 会给自己的 Pod 打上类似 prometheus.io/scrape: "true" 的标签。意思是：“嗨，如果有谁在收集监控数据，请来这里抓我。”

知识点：生产环境observability做法

Thu, 21 May 2026 20:34:27 +0800

观测逻辑链条

1
2
3
4
5
6
7


Prometheus
 ↓ select
ServiceMonitor
 ↓ select
Service
 ↓ endpoint
Pod /metrics

1.首先helm add:

1
2
3
4


helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 
helm repo update 
# 在 monitoring 命名空间下安装全家桶 
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

2.查你自己生产集群对象字段再做连接prometheus

kubectl get prometheus -n monitoring -o yaml | grep -A 5 serviceMonitorSelector

1
2
3
4
5
6
7


(base) savilahao@bogon ~ % kubectl get prometheus -n monitoring -o yaml | grep -A 5 serviceMonitorSelector
 serviceMonitorSelector:
 matchLabels:
 release: prometheus #你通过helm拉的一般都叫这个名字
 shards: 1
 tsdb:
 outOfOrderTimeWindow: 0s

Prometheus Operator只看有特定 Label 的资源，matchLabels这个key下是你需要告诉它的内容，后续写到k apply YAML 里 metadata.labels对象中
查Agones 暴露指标的靶子（定位 Service 和 Port Name）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 先看srv对象列表
(base) savilahao@bogon ~ % kubectl get svc -n agones-system | grep metrics
agones-allocator-metrics-service ClusterIP 10.101.11.151 <none> 8080/TCP 26h
agones-controller-metrics-service ClusterIP 10.109.209.46 <none> 8080/TCP 26h
agones-extensions-metrics-service ClusterIP 10.105.232.133 <none> 8080/TCP 26h
# 看对应srv对象的Port Name
(base) savilahao@bogon ~ % kubectl get svc agones-controller-metrics-service -n agones-system -o jsonpath='{.spec.ports[*].name}{"\n"}'
	metrics #同样的命令抓allocator和extensions的
# 看Agones 的 Service 自己带了什么标签
(base) savilahao@bogon ~ % kubectl get svc agones-controller-metrics-service -n agones-system --show-labels
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE LABELS
agones-controller-metrics-service ClusterIP 10.109.209.46 <none> 8080/TCP 26h agones.dev/role=controller,app.kubernetes.io/managed-by=Helm,app=agones,chart=agones-1.57.0,heritage=Helm,release=agones

kubectl get svc agones-allocator-metrics-service -n agones-system –show-labels

根据信息组成yaml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 name: agones-metrics
 namespace: agones-system #注意这里最好写业务的ns而不是我们刚才创建的monitoring ns
 labels:
 # 替换为你从第一步查到的 Prometheus Selector
 release: prometheus 
spec:
 endpoints:
 - port: metrics # 替换为你从第二步查到的 Port Name (可能是 http web)
 - port: http #我抓到allocator的是这个
 namespaceSelector:
 matchNames:
 - agones-system
 selector:
 matchLabels:
 # 替换为你从第三步查到的 Service Label
 app: agones

做check：

1
2
3


(base) savilahao@bogon ~ % (base) savilahao@bogon ~ % kubectl get servicemonitor -n agones-system
NAME AGE
agones-all-metrics 4m12s

进入 Grafana 监控室

kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

输入user和pw

补充，转发进入服务器指令：

kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80是Grafana 可视化界面的server ^f070bd
kubectl port-forward -n monitoring svc/prometheus-operated 9090用于Prometheus 服务器本身

import json 到dashboards后：当然这里有个小插曲，开始的时候都是红色三角no data, fix: add Data Source-Prometheus mannually 看板信号分析：

GameServers count per type (饼图) & count overview (折线图): 这两个图表显示，当前集群里只有 1 个状态为 Ready 的游戏服。结合下方的折线图，这条绿线一直平稳维持在 1，说明这个游戏服已经存活了一段时间。
GameServers per node & Node availability: 这两个底部的图表监控的是底层的物理资源。它告诉你，当前有一个 Node（也就是你的 Minikube 虚拟机）正在被“使用（used）”，并且上面跑着这个孤零零的游戏服。 Q:为什么Fleet RollOut Percentage, Fleet Replicas Count是No Data？当前集群里只有一个散养的单体 GameServer,并没有部署任何 Fleet资源证据：

1
2


(base) savilahao@bogon ~ % kubectl get fleet
No resources found in default namespace.

Grafana监测实验：部署gameServer舰队！(Fleet对象)

kubectl apply -f :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


cat <<EOF | kubectl apply -f -
apiVersion: "agones.dev/v1"
kind: Fleet
metadata:
 name: simple-game-fleet
spec:
 # 我们要求集群里永远保持 5 个 Ready 状态的游戏服
 replicas: 5
 template:
 spec:
 ports:
 - name: default
 containerPort: 7654
 template:
 spec:
 containers:
 - name: simple-game-server
 image: us-docker.pkg.dev/agones-images/examples/simple-game-server:0.35
EOF

我们的舰队all set!!!

1
2
3


(base) savilahao@bogon ~ % kubectl get fleet
NAME SCHEDULING DESIRED CURRENT ALLOCATED READY AGE
simple-game-fleet Packed 5 5 0 5 5m23s

爽看Grafana： ^b3ca9b

Q：“General，鄙人突然想把这支新组建的舰队都干掉怎么办？”

1

kubectl delete fleet simple-game-fleet

k8s生产化项目-Agones导学（May20）

Wed, 20 May 2026 00:00:00 +0800

书接上回，现在我们部署好了gameserver和监控系统，现在还要研究agones的两个核心功能：模拟玩家进场和动态扩缩容依赖的组件：

FleetAutoscaler：基于缓冲区的自动扩缩容
GameServerAllocation：模拟Matchmaker分配房间服务器![[参考文档#^6dde12]]

k8s生产化项目-Agones导学（May19）

Tue, 19 May 2026 00:00:00 +0800

安装与配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 安装
brew install kubectl
brew install helm
brew install minikube

# 创建minukube k8s cluster
minikube start \
--kubernetes-version v1.34.6 \
-p agones \
--driver docker \
--cpus 4 \
--memory 8192

配置MetalLB

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


# 安装 MetalLB
helm repo add metallb https://metallb.github.io/metallb
helm repo update
helm install metallb metallb/metallb \
--namespace metallb-system \
--create-namespace
# 安装好都就绪后先minikube ip -p agones看IP然后配置IP地址池
cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: default-pool
namespace: metallb-system
spec:
addresses:
- 192.168.49.50-192.168.49.250 # 从 minikube ip 的⽹段分配
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: default
namespace: metallb-system
spec:
ipAddressPools:
- default-pool
EOF

安装Agones helm repo add ; helm repo update ; helm install agones xx

部署服务 kubectl apply -f https://raw.githubusercontent.com/agones-dev/agones/release-1.57.0/examples/simple-game-server/gameserver.yaml

minikube tunnel -p agones 修改macos路由表，让所有发往整个 LoadBalancer 网段的包都走特定网关IP，从而可以转发到k8s集群内部

外部可以ping通但是无法udp连接(我用 minikube tunnel -p agones之后也不行)，进入minikube ssh -p agones后发现可以ACK返回测试正常

停止集群运行：保留磁盘但是释放内存和cpu minikube stop -p agones

看minikube整体情况 minikube profile list

看某个profile的局域网IP minikube ip -p agones 看Agones GameServer 的分配端口： kubectl get gs -n <namespace>

安装成功后测试

1
2
3
4


# 看gameserver的IP和端口后
docker@agones:~$ nc -u 192.168.58.2 7621
kk
ACK: kk

这里证明 UDP 包已经成功打通了 Minikube 的网络，并被游戏服接收并回包。

体会agones项目的工程魅力

kubectl describe gs simple-game-server-pwdww

可以看到events：

1
2
3
4
5
6
7
8


Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal PortAllocation 7m38s gameserver-controller Port allocated
 Normal Creating 7m38s gameserver-controller Pod simple-game-server-pwdww created
 Normal Scheduled 7m37s gameserver-controller Address and port populated
 Normal RequestReady 7m36s gameserver-sidecar SDK state change
 Normal Ready 7m36s gameserver-controller SDK.Ready() complete

Status部分，看看 Agones 是如何把端口映射和宿主机 IP 同步到资源状态里的

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


Status:
 Address: 192.168.58.2
 Addresses:
 Address: 192.168.58.2
 Type: InternalIP
 Address: agones
 Type: Hostname
 Address: 10.244.0.25
 Type: PodIP
 Eviction:
 Safe: Never
 Immutable Replicas: 1
 Node Name: agones
 Players: <nil>
 Ports:
 Name: default
 Port: 7621
 Reserved Until: <nil>
 State: Ready

一个实验，体会pod优雅退出（gameserver业务逻辑：自己决定自己的生死，不由k8s调度机制杀掉）：

实验：在nc -u中发送EXIT信号，观察容器状态编程退出观察这个gm完整的生命周期：给pod发送EXIT信号这个pod就自动把自己删除了，k get pod -A 不会看到 0/1 ，这是gameserve的业务逻辑，一个游戏结束后该服务器就完全释放掉了

理解agones重要工程机制

kubectl logs simple-game-server-rcsxb -c agones-gameserver-sidecar 密密麻麻的输出中，

"grpcEndpoint":"localhost:9357"
"httpEndpoint":"localhost:9358" 这说明 Sidecar 启动后，在 Pod 的内部网络空间（localhost）死死地守住了这两个端口。监听信号：

游戏进程启动时，它其实是向 localhost:9357（Sidecar 的端口）发送了一个 /Ready 请求。当你敲下 EXIT 时，你的程序也是向 localhost 发送了 /Shutdown 请求。业务代码完全不需要懂怎么调用复杂的 Kubernetes API。它只需要和同 Pod 内的本地 Sidecar 通信。Sidecar 收到指令后，替你去和 K8s 的 API Server 交涉，修改 CRD 的状态。这就是典型的解耦设计。

kubectl get pod simple-game-server-rcsxb -o yaml | grep hostPort

1
2


# 输出
 hostPort: 7078

Agones 暴躁地跳过了 K8s 标准的 Service 负载均衡，直接将宿主机的网卡端口和容器内的 UDP 端口硬绑死。刚才用 nc 连的 192.168.58.2 根本不是一个虚拟 IP，那是 Minikube 虚拟机的真实物理 IP。Agones Controller 在后台帮你维护了一个庞大的端口池，自动避开端口冲突，实现了网络直通（Direct Routing）。

在原生 K8s 中，是 Kubelet 定期去Probe你的 Pod 活没活着。但在 Agones 中，这个逻辑被反转了。日志会看到游戏程序在疯狂地、周期性地向 Sidecar 发送心跳包。机制揭秘：游戏服一旦卡死（比如死锁），Kubelet 的外部探测可能无法察觉业务逻辑层的假死。Agones 要求业务进程主动调用 SDK 上报 Health()。一旦 Sidecar 一定时间内没收到心跳，Sidecar 就会直接向 K8s 宣告这个游戏服处于 Unhealthy 状态，触发后续的回收逻辑。该心跳机制可以看日志：

1
2
3
4
5
6
7
8
9


(base) savilahao@bogon ~ % k logs simple-game-server-rcsxb
Defaulted container "simple-game-server" out of: simple-game-server, agones-gameserver-sidecar (init)
2026/05/20 06:15:09 Creating SDK instance
2026/05/20 06:15:09 Starting Health Ping
2026/05/20 06:15:09 Marking this server as ready
2026/05/20 06:15:09 Starting UDP server, listening on port 7654
2026/05/20 06:15:09 Health Ping
2026/05/20 06:15:11 Health Ping
2026/05/20 06:15:13 Health Ping

做下observability(Prometheus + Grafana)

[[知识点：生产环境observability做法]] agone项目暴露了很多观测借口，

1
2
3
4


helm repo add prometheus-community https://prometheus-community.github.io/helm-charts 
helm repo update 
# 在 monitoring 命名空间下安装全家桶 
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

创建一个 ServiceMonitor 资源，把 Agones Controller 的指标端点暴露给它:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


cat <<EOF | kubectl apply -f -
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: agones-all-metrics
namespace: agones-system
labels:
release: prometheus
spec:
namespaceSelector:
matchNames:
- agones-system
selector:
matchLabels:
 # 靠这个标一网打尽三个 Service
 app: agones
endpoints:
# 匹配 Controller 和 Extensions
- port: metrics
# 匹配 Allocator
- port: http
EOF

可以查到这个serviceMonitor对象创建成功：

1
2
3


(base) savilahao@bogon ~ % kubectl get servicemonitor -n agones-system
NAME AGE
agones-all-metrics 4m12s

端口转发+登陆Grafana： kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80 看密码![[知识点：helm#^ebfc61]]

进入grafana后import json, json哪里来？从官方项目复制 curl -LO https://raw.githubusercontent.com/agones-dev/agones/main/build/grafana/dashboard-gameservers.yaml

最终看板效果![[知识点：生产环境observability做法#^b3ca9b]]

写在实验结束：

minikube资源生命管理层级：

minikube pause -p agones ->不占CPU了，但是内存依然在吃
minikube stop -p agones ->Graceful Shutdown，给Kubelet 和所有的 Pod 发送 SIGTERM 信号，CPU和占用内存都释放掉
minikube delete -p agones -> 毁灭整个集群，释放CPU和内存，同时连带之前写入的磁盘资源一并释放

Q：下次如何恢复之前的状态？ Kubernetes 是Declarative的架构，依赖etcd 的分布式键值数据库，所有数据都做了持久化，理论上不需要我做什么minikube start -p agones就可以恢复，不过监测这里我还要输port-forward命令连到grafana server，另外就是Grafana 面板可能需要在dashboards中重导个那个json文件![[知识点：生产环境observability做法#^f070bd]]

总结

我的暴露出来的一些弱点：

对网络层级的理解一般，本次ICMP可通但是TCP不通其实可以用cn的知识很好理解但是i cant
对Kubernetes的网络入口机制不清楚，不知道NodePort Ingress 这些都是干嘛的，概念都没有，not to mention结合这些设计原理进行网络排查