第 14 期 - 一起擺脫開工倦怠期

本週專欄

Kubernetes 教學 (一) 概念與架構 - 為什麼該學 K8S ？Pod？Node？搞的我好亂呀

為什麼該用 Kubernetes? 使用 K8S 的概念可以有哪些好處？真的值得我們一用嘛？好，我們知道為什麼要用了，那接下來，開從哪裡開始，我們從 K8S 的架構開始認識，了解一些重要名詞，開始我們的 K8S 之旅。

神 Q 超人

如果你想成為產品經理，我的8個建議

在職涯規劃中，要不要轉為 PM 一直都是工程師選擇的路之一，但是誰也不曉得這個決定到底是不是正確的，如果各位朋友在新的一年中，也剛好想嘗試看看自己是否踏上「產品經理」這層階梯，但又對這職位感到高度沒安全感，不如先看看文章內給出的幾點建議。

A JavaScript interview question asked at Google

我很喜歡看一些面試題，尤其是剛好看見之前被問過的題目，那就更棒了！這篇文章中分享的問題是如何以 JavaScrip 實現類似 Listener 功能的 Class，大家也不妨照著文章一開始描述的題目內容試著實作一遍吧！

How to Write Beautiful and Meaningful README.md

製作一個 SideProject 雖然很困難，但是要寫出漂亮的 README.md 更讓人傷透腦筋，就像文章內提到的「有些開發者會花一個小時來調整按鈕的邊距，但卻無法用十五分鐘好好描述這個 Project 的內容」，如果你也有相同的困擾，或是 README.md 上永遠都只有 Project 的名稱，立馬一起學學 🙌

Larry Lu

瀏覽器的時光機—歷史堆疊、 pushState 與 replaceState API

隨著現在的前端日漸複雜、前端也有自己的路由系統，有時候瀏覽器預設的上一頁、下一頁功能不見得是開發者想要的，為了讓上下頁能達到預期的效果，這時候只好用 pushState 跟 replaceState 來操作歷史紀錄

多想三分鐘，你可以少欠很多技術債

在進行軟體開發時難免都會產生技術債，不可能完全避免，但如果能在事前做好規劃就能少欠很多債，這篇文章用實際例子教你怎麼分析系統，讓你的系統往一個正確的方向前進

React Performance Fixes on Airbnb Listing Pages

Airbnb 的前端是出名的強，這篇是由他們團隊分享怎麼做 React 的效能測試、還有講解怎麼看火焰圖，讀完這篇保證可以讓你變成更強的 React developer

LukaTW

REST API Guide

深度了解 REST API 指南，非常完整到位解釋了 REST 的重點。為什麼要使用 REST？ 六個 REST 架構的限制分別是哪些？又為什麼要設計這些限制？ 理查德森成熟度模型又是什麼？怎麼實踐 REST？然後還附上範例，真是太補了。

71 Python Code Snippets for Everyday Problems

用問題來分類，用 16 個分類，分類各種需要處理的情況，71 個程式碼片段，來幫助你高效率的腳絕 Python 問題。真實用，作者的網站經營的也很出色，值得一看。

Top 10 errors from 1000+ Ruby on Rails projects

10 個最常見的 Ruby on Rails 錯誤與解決他們的方法。雖然在 2020 年 Ruby on Rails 又死了一次，但是還是可以藉由這篇來幫助還沒有死掉的 Rails 專案更快速的除錯。

smalltown

Kubernetes Pod 的 Resource Request & Limit 到底要怎麼設定？！

常常會被問這個問題，但其實自己無法回答，當然不是因為很小氣不肯說XD 而是因為每個人所撰寫出來的應用程式所需要的 CPU 和 Memory 最低限度需要多少必須要經過壓測才有辦法得知，也才有信心知道自己的應用程式在目前的資源底下可以服務多少的使用者，這篇文章就 K8S Pod 設定 Limit & Request 時可能會被怎樣對待給出清楚的說明

• 首先將 Pod 分成三種類型

  • Guaranteed: Pod 裡面的所有 Container 都有設定 Request & Limit，而且值都一樣
  • Burstable: 沒有任何一個 Container 在 Pod 裡面的 CPU 或是 Memory 設定為 Guaranteed
  • Best Effort: Pod 沒有設定 Request 或是 Limit

• K8S Cluster 就是根據設定的 Request & Limit 來將 Pod 分配到適合的 Node 中，所以假如某一個 Pod 設定的 Request 大於目前 Node 可以承擔的資源時，那這個 Pod 就會找不到 Node 可以去，導致一直處於 Pending 的狀態；當 Request 設定的值太大時將無法被分配到任何的 Node，除此之外也可能會導致被霸佔但沒有使用到的資源無法被其他的 Pod 使用，這時候管理 K8S Cluster 的同事可能會站到你座位的後面看著你…

• K8S Cluster 在分配 Pod 到適宜的 Node 上時，並不是那麼地直覺，是以底下這兩個值的較大值為主：

  • Pod 裡面所有 Container Request 的總和
  • Pod 裡面任一個 Init Container 的 Request

• 當 K8S Cluster 資源不敷使用時，Kubelet 便會變成劊子手，開始將一些 Pod 給砍掉，而砍掉的順序會是如何呢？

  • 首先砍掉已經死掉的 Pod，沒有在用的 Container Image 將 Disk 空間給釋放出來
  • 接下來就是把沒有設定 Request 或是 Limit 的 Best Effort Pod 給砍掉
  • 然後把使用到的資源比 Request 來得多的 Burstable Pod 給砍掉
  • 最後再把使用到的資源比 Request 來得少的 Burstable Pod 給砍掉

• 所以可以得知，假如某個 Pod 相當重要的話，那就一定要將其設定成 Guaranteed Pod，避免它在 Node 資源不充足的時候被砍掉；不過有一個例外，就是當 K8S 本身的系統服務需要更多運算資源才得以正常運行時，這種情況之下 Guaranteed Pod 才會被 Kubelet 給砍掉

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢，但是又沒有那麼多錢，只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業，一切跟產品有關的知識，都是我們的守備範圍！

Curators:

• @GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
• @Larry850806 - 我是 Larry，傳說中的 0.1 倍工程師！
• @LukaTW - 一名全身都是死角的工程師。
• @smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術

Feedback

想看什麼內容，告訴我們！ 點我回饋意見