Kros 積分 0

對,簡單來說就是不吃早餐~但是難的是要嚴格執行,還有在這兩餐之中要吃到基礎代謝。

IngramChen 積分 0

大概掃了一下,還沒仔細看

像是 一天 1pm -> 7pm 吃飯這樣?這好像很多人做過,就單純的不吃早餐,我小時候懶也不吃早餐…

Kros 積分 0 編輯於

在這個 Framework 中他分成三個維度:

DR: Dietary restriction (what you eat or don’t eat)
CR: Caloric restriction (how much you eat )
TR: Time restriction (when you eat and don’t eat )

他曾經嘗試過 22/2 斷食,每天用2個小時的時間吃完一天所需食物,他的感覺是跟生酮的效果差不多。

建議是:
1. 至少要實行一種維度 (通常是 TR)
2. 可以常常實行兩種 (通常是 TR + CR)
3. 偶爾可以三種一起

Kros 積分 0
作者簡介:

彼得·阿提亞(Peter Attia)醫師在低醣界大概算神人級的吧,常常進行N=1的自我實驗,他有個知名的部落格,部落格名稱從一開始的『向胰島素宣戰』(The War on Insulin),後來變成『飲食學院』(The Eating Academy),目前名稱是他的名字 Peter Attia MD,裡面有關於營養、運動、長壽、生酮飲食、間歇性斷食、脂質學、mTOR、rapamycin等等各方面,非常多的資訊,而近幾個月他開始錄製Podcast,訪問各領域的人,也非常值得一聽。 (🔗Refrernce: 逆向工程分析人類要如何長壽1

IngramChen 積分 0

我們家自己架的 artifactory 很舊,remote repo 都沒 https,看了這篇才發現...

IngramChen 積分 0 編輯於

nginx cert-manager 大概只要是 bare metal 都是這樣做,在自己的主機玩都這樣。

一開始我們先用 ALB,因為 ALB controller 雖然現在沒有可以共用 path rule,但其實已經做好了,等待 alpha 測試完畢就可以用了。結果沒想到一等就等半年 (作者太忙,他們都 AWS 的人)。所以現在卡的不上不下的,如果打掉重練的話可以重新考慮 nginx 的作法。

不過, NLB 進來的封包,會先經過 kube-proxy (iptables 吧?),再到 nginx pods,再到 app pods,一個封包在 nodes 間 bounce 兩次以上這種事我實在是受不了… 如果 node 是跨 Availability Zone 的話,每次 bounce AWS 都要收錢的

popcorny 積分 1

SSL Termination 可以用 cert-manager,用 let's encryption issuer1 其實挺無腦的。他好像沒有提到 ALB 比較貴的缺點,我怎麼看都覺得 NLB + nginx 比較好。話說我們用 GCP 也是用 L4 LB + nginx ingress 唷。

koji 積分 1

https://www.reddit.com/r/StreetFighter/comments/em24ck/releasesfvnetcode_fix/

真是即時的文章XD...

IngramChen 積分 0

文中有寫到和 ALB 的優缺點,對我們而言比較重要的就是 ssl termination 了。NLB+nginx 的組合 ssl 就要自己管,有點麻煩

IngramChen 積分 0

node 現在有 managed node & fargate 可以用

兩者都不支援 spot instances, 然後 fargate 不支援 EBS,暈倒

ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站

哎,就是麻煩啊,k8s 的難度已經很高了,還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods,這算是 EKS 的優點。

cloudsql 聽到有 downtime 是一兩年前的事了,現在還會遇到嗎?拿麼恐怖

kakashi 積分 1

恩恩 感謝回覆我的問題!!! 不過我知道有些點有改善

  • master 要錢 <--- 真的貴
  • node 現在有 managed node & fargate 可以用 (心智成本又上升了)
  • GKE 其實到最後還是要熟 VPC 的部分,我們家有踩到一些雷,最後還是自己重切過
  • ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站
  • EC2 網卡這個我認同, 這個東西每次都要查一下,蠻麻煩的 Link1

GKE 我覺得很棒,但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定, 像是 cloudsql 會有 downtime 就抖抖的,這方面可能再跟大家請教下 XD

indigo 積分 1

Sonos executives said they decided to sue only Google because they couldn’t risk battling two tech giants in court at once.

IngramChen 積分 0 編輯於

Google GKE 大概是做最好的吧,這也是去年 GCP 用戶上升的原因。

EKS 就是個拼裝車,把 AWS 現有的服務硬裝上 k8s,所以變成用戶除了使用 k8s 外,還要處理 AWS 本身的服務,以及橋接的部份。

  • EKS 的 master 要錢,mdfk
  • EKS 的 node 要自己安裝升級,還要一台台自己手動升,mdfk
  • EKS 還要先設好 VPC,VPC 除了設一堆 route table 外還要買固定 IP,然後超級難懂,mdfk
  • EKS 的 ingress 是不能共用 Load Balancer (ALB) 的,所以每個對外的網址都要開一台 LB,你開十個小站就要花十台 LB 的錢,mdfk
  • EKS node 延用 EC2 的網卡架構,舉例一台小 node 如果能配四張網卡,而一張網卡只能配四個 IP 的話,你一台 node 就只能裝 16 pods 左右,不論你 cpu/ram 還剩多少空間,mdfk
kakashi 積分 0

其實蠻想知道爛在哪 XD 有比 EKS 好的選擇嗎?求解

changyuheng 積分 0

雖然目前還缺乏 tagging,不過編輯部分的 Ux 已經超越了 Bear1 (IMHO)。

Kros 積分 1

SFV 台灣的問題是海底電纜頻寬不夠了,連到國外都還是 lag,只有非巔峰時期正常

IngramChen 積分 1

我們用 AWS EKS,目前的更新計畫是 慢一版 (例如 EKS 升到 1.15 了,我們才會從 1.13 升到 1.14),週期大概是半年,更新的時候順便會一起升工具鍊 (helm 什麼的)

K8s 沒有 LTS 版,所以我傾向慢一版才更新 (等 bug 都抓完了),然後 EKS 又特別慢 ,官方已經 1.17 了,AWS 到現在 1.15 還沒生出來,所以大部份的情況我們團隊會慢 3~4 版左右。

雖然更新很慢但 k8s 到了 1.1x 版左右就很成熟了,目前沒什麼大問題。有問題的是 EKS。

===== EKS 爛到有剩 =====

IngramChen 積分 0

值得好好讀完. 其他領域也有可能會用到

kaif 積分 0

全世界都抄s3 api啊,真的標準是cdmi沒人裡他。aws也沒差吧,沒一個能打的

IngramChen 積分 0

https://www.ithome.com.tw/news/135153

中文