更新一下，又不理解了，看 jimmysong 的文档，东西网关 outbound handler 规则，route 和 endpoint 都在的，但是没法像文档里说的一样进行路由。
唯一的区别是，他说的是向 host=ratings.default.svc.cluster.local 的请求，我设定的路由是向自定义域名的 host=internal.service.com 这样的。pod 里就显示 dns 解析问题了。

发现这就是官网上说的 mesh gateway （东西向），但是是 experimental feature ，需要开启 CRD 才能用。
但 CRD 的 github 链接又 404 了。。。

```
Note that this document uses the Gateway API to configure internal mesh (east-west) traffic, i.e., not just ingress (north-south) traffic. Configuring internal mesh traffic is an experimental feature of the Gateway API, currently under development and pending upstream agreement. Make sure to install the experimental CRDs before using the Gateway API:
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.6.1" | kubectl apply -f -
```

@lidashuang #4 你意思是用 gateway=mesh 把路由规则发布到每个 pod 的 sidecar envoy 里？这个已经做到了。
但测试发现这些路由规则是请求进入 service/pod 时(inbound)才能触发的。（本来以为可以 outbound 时就能使用这些路由规则）
所以我需要在 pod 里先请求到某个 service （任何一个 service ），在那个 service 的 inbound 处理那儿，才能使用这些路由规则。就让这个请求多了一步。
理想的情况：请求者 pod 发出请求 -> 自己 sidecar 路由规则 -> 目标 service ，就完成请求了。
现在只能找到的路线：请求者 pod 发出请求 -> **集群内任何 service** -> 那个 service pod 的 sidecar 路由规则 -> 目标 service 。
这个请求就多绕去了一个 pod 。有点失去了 mesh 的意义，我们之前用的统一 envoy gateway 就是这么工作的。

@ermeow #3 对，就是 path->service 的基本功能。
发现 virtual service 定义给 sidecar 的规则是放在 sidecar 的 ingress 里的？（不是 egress outbound ，有没有什么方法能 outbound 时就触发规则？）
如果 pod 里发出的请求想触发这些规则，就得先发给某个 pod 的 sidecar ingress 才行，然后才能通过规则找到真正的目标 service 。
*所以我想如果真的只能在 inbound 时使用规则，那请求 pod 自己的 sidecar inbound ，算是最小化路径了。

@tanxnative #1
virtual service
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-vs
spec:
hosts:
- "testapi.host.com"
gateways:
- mesh
http:
- match:
- uri:
prefix: /status
- uri:
prefix: /anything
- uri:
prefix: /headers
route:
- destination:
host: httpbin.default.svc.cluster.local
port:
number: 5000
```
`curl -H 'Host: testapi.host.com' http://any-other-service.default/anything`是可以的

`curl -H 'Host: testapi.host.com' http://172.16.153.111.default/anything`是可以的（ IP 是任何自己 service 的 cluster ip ）

但是

`curl -H 'Host: testapi.host.com' http://10.73.3.111/anything` 就不行了（ IP 是自己 pod 的 ip ）
报错`curl: (7) Failed to connect to 10.73.3.111 port 80 after 0 ms: Connection refused`

尝试请求传说中 sidecar http inbound 端口也不行：
`curl -H 'Host: testapi.host.com' http://127.0.0.1:15001/anything`
`curl: (56) Recv failure: Connection reset by peer`

BBA 只能说不丢面子，毕竟车不一定贵，4S 店保养价格是统一的贵。
LZ 当老板的还是干销售的？
写代码的打工人好像不需要吧？能想到最大的好处是大部分小区看门大爷会给 BBA 直接放行。

@littlesubgirl #60
@digimoon #63
之前配置是 3700x+1070ti ，没超频，插专门测功率的插座上测试的，开机后什么都不干大约 120w ，vmware 虚拟机开一个后会再多一些。

游戏 pc 待机一般 100w 以上，一天 2.4 度电，假设 1 元，一年待机电费也要 350 。真实还要加上硬盘,跑服务的功耗。
估计两年多花的电费够你买个入门专用 nas 了。

不追求 3A 高画质，steamdeck 真的很不错的，追求 pc 游戏仪式感可以插显示器玩。

什么电视？很多电视即使是游戏模式，延迟也大的不适合玩游戏的哦。

request 决定 pod 被分配到哪个 node 上，32 核的机器，cpu request 之和到 32 就不会编排新 pod 了。
limit 决定单个 pod 最多能用多少。
cpu limit 建议至少 1 ，不然相当于被强制限速。
然后用 CPU request 来设计 pod 的分布，一般是按启动后稳定下来的 CPU 使用量估算，防止把 node 撑爆。

只能使用邀请码

niz atom66 ，宽度完美适配 13 寸 macbook 。感觉四个脚垫也是为了放在 macbook 键盘上方设计的，排列方式正好避开了 mac 键盘区域。

接的 API ，且没有办法使用上下文...少了一大半的用途。

其实用 apple silicon 最大的缺点是 docker 镜像版本会有区别。
默认 pull 下来的，和本机打包出来的，都是 arm64 的镜像。放到 x86 服务器上不能跑。
pull 下来上传的话，需要加上 --platform=linux/amd64
build 给服务器用的镜像的话，估计得找个 x86 的云服务器打包。

@Frankcox #7 时不时的本地开发和测试一些服务，用虚拟内存没什么问题。
我 16G 的 mba ，用 docker for mac 里的 k8s 集群，调试 istio 配置，再开十几个小服务用来测试，会用几个 G 的虚拟内存（其实大部分只是 docker 提前占用着，服务本身没用多少）。
*8G 内存长期(永远在大量的)用虚拟内存会伤害一点硬盘。

@nieboqiang 提醒一下，汽油有 3 个月保质期的哦。

如果公司有固定 ip 的网络的话，搭一下 ipsec vpn ，阿里云那儿大概一个月 200 的费用吧。

@simplereasy 如果基本都是对文字的话，27 寸 4k 的文字清晰度感觉会好不少。至于够用嘛，24 寸 1080p 的适应了后也够用。

不过，苹果上一代官方显示器就是 27 寸 2K 的，所以适配支持肯定没问题的。
其实更推荐 21:9 的带鱼屏，34 寸 2K 的横向分 3 个窗口也非常舒适，基本可以当双屏用。

rsync