投资这东西，手上本金少的话，搏大的才能赚到你付出的机会成本，但潜在回报率那么高的话就成了赌博，不推荐。
不赌博。积累资源，做足功课，全身心的投入，可能能跑赢大盘一点点。
如果本金不多的话，赚得也不多，浪费这个精力没意思。

建议是学习学习微观和宏观经济学，知道不同的周期把钱放哪儿比较好，然后适当关注经济新闻，学会大概判断在哪个周期。买一些稳定的产品，偶尔能小赚一点，万一亏也亏不了多少。

感觉是因为苹果丐版性价比其实挺高的，吸引到那批价格敏感型消费者了，然后把人勾引来了，发现升配价格高于预期，就不开心了。这不也没见他们吐槽 mac pro 一台几十万，也没见他们吐槽升级 8TB 硬盘的价格么。

考虑买 surface ，甚至买 xps13 的人，不是这类人群。他们看到价格后就毫无感情的去看别的选项去了。

当然，强绑定苹果生态的，可能也会抱怨几句，然后买个丐版，外接个 SSD 之类的。

按现在的技术，可能能做一些比较简单的，比如训练一些企业专用的客服机器人，并且需要所有挖矿机器都有至少 12G/24G/32G 显存。比如把那些 4090 用起来，激励一批手动给显卡加焊内存的人。

解决了，最后发现是需要添加个 ServiceEntry ，把 internal-service-com(FQDN) 添加到 dns 里去。
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
name: testapi
namespace: fortune
spec:
hosts:
- "<my-fqdn>"
location: MESH_INTERNAL
ports:
- number: 80
name: http
protocol: HTTP
resolution: DNS
然后 virtual service 的规则，在 outbound handler 是可以正常处理请求的。

更新一下，又不理解了，看 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 内存长期(永远在大量的)用虚拟内存会伤害一点硬盘。