前天我在 2019 台灣雲端大會帶了兩個場次，一個是現場實作場次，一個是經驗分享演講：

• Lab / 給 RD 的 Kubernetes 初體驗 (90 minutes)

• Speech / 當 .NET 遇到 Kubernetes (30 minutes)

兩個場次，一言以蔽之，都圍繞在 Kubernetes 的入門認知與導入策略上。

四月 9–11 日去舊金山參加 Google Cloud 的 Next ’19 大會，收穫頗大。

這場大會，同一時段就有近 30 場專題演講同時進行，議程滿滿，勢必得做取捨。基於工作需要及個人興趣，我主要選擇與容器相關的場次：service mesh、Windows containers、混合雲、資安實務。

我發現，光是這些場次，就得花很大力氣去消化、實驗與應用。

我們這些所謂的「台港團」會在 GCPUG Taipei 舉辦一場分享會。因為自己不克參加，便以這篇文章，針對我鎖定的核心議題：Istio，做一番重點摘要，以饗讀者。

既然要開始在 Windows 上沿用 Mac 及 Unix 的命令列工具習慣¹，免不了要處理 Ansible 及 Vagrant。

雖然這兩個軟體都有對應的 Windows 版本，但據我以前的經驗，卡卡的，有許多小地雷；畢竟這些發跡自泛 Unix 家族的軟體，不是那麼容易無縫移植到對命令列不友善的 Windows 家族。

如今 Windows 已經有 WSL (Windows Subsystem for Linux) 機制，是否可以更無痛享用 Ansible 及 Vagrant 呢？

可以的。

在 Windows 10 上面使用 WSL 已經一個月了¹。小狀況也就罷了，但 Cmder 不夠穩定的顯示邏輯卻最讓我頭痛，在視窗尺寸變化時，無法正確處理字元位置。更令人費解的是，即使是其他狀似更華麗（也更耗資源）的替代方案，也仍然有這些問題²。

既然酷炫的終端機競品問題多多，乾脆回歸極簡的 WSLtty³，並混搭 tmux⁴ 來彌補。可惜，畢竟是組合技，無法完全複製 Mac 的 iTerm2 使用經驗。

此事古難全。

API gateway 是微服務環境，甚至 service mesh 的要角 ¹。

在 Kubernetes 上面，API gateway 選項眾多。有像 HAProxy 及 Nginx 這些石器時代老傢伙跨足過來，也有打從一開始就走 cloud native 路線的後起之秀。

該如何選擇？