Cloud Run 是 Google 的 Serverless 產品，讓我們不用管理基礎 infra 也能建置容器，並會根據流量自動調整資源，且只依據實際使用的資源收費。 這邊特別注意一下，目前 Cloud Run 似乎還沒支持 ARM 格式的 image，故有使用 M1 筆電包 docker image 要特別注意一下，這會出現不可預期的 bug !
現在公司很多都會給新進員工配上 Apple M1 筆電，整體筆電用起來都還不錯的。但因為 Apple M1 底層處理器架構大改變，對於軟體開發在本地端測試時候，常發生一些不可預期的狀況。這邊就來記錄一下有遇到的 BUG。
kubectl 是針對 k8s cluster 的 API Server 發送命令的工具，有些指令會改變 K8s cluster 的 state 和任何對應到的環境變量。默認情況下，kubectl 在 $HOME/.kube 目錄下查找名為 config 的文件，kubectl 使用該 config 文件來查找要通訊的 K8s cluster 資料。
這道題要我們從有序數組中去除重複項，題目難度雖然被歸為 easy 等級，但在條件限制上的討論，蠻多東西可以釐清討論的。 英文方面寫得蠻長，記得要看到最後因為有寫一些限制如 :
- O(1) extra memory
- The relative order of the elements should be kept the same.
所以不能用 Set 或另開 array 去寫。另外也花了些篇幅去說明，只要原 array 前面長度部分內，有把所有不重複數字列出來就好，不需要在意後面 array 的元素和 array 的長度。
在上一篇文章中，簡單介紹了 Kubernetes 的架構，接下來簡介 Kubernetes 在部屬 app 時的單位 Pod 。 Pod 對多容器的支持是 K8 最基礎的設計理念，但 Pod 應該怎麼被管理呢 ? 怎麼和外網連線呢 ? 這些部分由如下元件提供功能解決 :
- Deployment
- Service
- Ingress
像在實現進階的操作如:負載均衡、滾動更新、安全與監控等概念，都會跟這些元件有關係。
從第一次聽到 Kubernetes 以來，已經有一年多了，永遠都記得 k8s 名稱的由來只是保留「開頭 K」及「結尾 S」，然後中間的英文字母數量剛好是 8 個英文字就這樣命名了…。全球三大雲服務商，AWS、Azure 和 GCP 都有提供託管 Kubernetes 集群服務( EKS、AKS、GKE )，可見其有名火熱程度。現在終於有機會在工作上碰到這項技術，就來寫些簡單筆記吧 !