防詐3要訣：不聽信、不操作、掛斷電話 
9
680612
查詢門市庫存
EKS 從不會到入門，從入門到精通
第一本完整探討 EKS 本土書籍
透過問題分析與討論讓你培養問題解決的脈絡
第一本完整探討 EKS 本土書籍
透過問題分析與討論讓你培養問題解決的脈絡
內容簡介
EKS 從不會到入門，從入門到精通
第一本完整探討 EKS 本土書籍
透過問題分析與討論讓你培養問題解決的脈絡
本書內容改編自第 14 屆 iThome 鐵人賽 DevOps 組的優選系列文章《那些文件沒告訴你的 AWS EKS》。
本書從建立 EKS cluster 開始，由「為什麼」為引言反思AWS是如何引用原生 Kubernetes 功能並設計，並溯源 Kubernetes 的原理，進而學習底層 Linux 及網路相關知識。此外，每章節提供逐步除錯驗證，照著步驟實作也能學習到除錯概念。
全書提供 18 個「為什麼」，使用「五個為什麼（Five whys）方法論一層層從 AWS、Kubernetes、容器，最終至作業系統，沿著因果關係順著網上探討釐清整體脈絡。這些「為什麼」們包含了數個 EKS 上實務常見問題，讀者除了能熟悉 AWS 環境及 Kubernetes 限制，也同時釐清作業系統與網路脈絡，提升問題排除的能力，進而持續精進「打破砂鍋問到底」的研究精神。
【目標讀者】
• 想要掌握 Kubernetes 概念和原理的工程師
• 想從 Junior 晉升到 Senior 的 DevOps/SRE 工程師
• 沒有使用過 AWS 雲端環境入門者
• 喜歡親自動手驗證的工程師
產品目錄
CHAPTER 0 為什麼寫這本書
0.1 誰適合本書
0.2 本書內容
0.2.1 會包括以下內容
0.2.2 你需要準備什麼？
0.3 如何使用這本書
0.4 「為什麼」這麼重要
0.5 實務操作
CHAPTER 1 建立 EKS 叢集環境
1.1 版本
1.2 建立環境
1.3 其它方便的設定
CHAPTER 2 CloudWatch Logs 及 CloudWatch Logs Insights 簡介
2.1 CloudWatch Logs 服務專有名詞
2.2 CloudWatch Logs Insights 查詢語法
2.2.1 CloudWatch 控制台
2.2.2 AWS CLI 命令
CHAPTER 3 為什麼 kubectl可以存取 EKS 叢集
3.1 叢集身分驗證
3.2 AWS IAM Authenticator for Kubernetes
3.3 驗證EKS 叢集預設使用AWS IAM Authenticator for Kubernetes
3.3.1 kubectl
3.3.2 驗證控制平面記錄檔
3.3.3 aws-iam-authenticator server 原始碼
3.4 流程
CHAPTER 4 為什麼 EKS 工作節點可以自動加入 EKS 叢集
4.1 EKS node group
4.2 Amazon EKS optimized Amazon Linux AMIs
4.3 kubelet 啟動程序（bootstrap） 初始化步驟
4.4 驗證 kubelet TLS bootstrapping 及自動化核准發證設定
4.4.1 kubelet 設定檔
4.4.2 kube-apiserver
4.4.3 kube-controller-manager
4.4.4 建立一個 EKS 節點
CHAPTER 5 為什麼 EKS 叢集可以識別預設 CNI plugin 為 Amazon VPC CNI plugin
5.1 工作節點 - kubelet 及 CNI
5.1.1 Kubernetes 1.22 版本
5.1.2 Kubernetes 1.27 版本
5.2 驗證EKS-optimized AMI 是否預設設定Amazon VPC CNI plugin 設定檔案
5.2.1 未加入 EKS 叢集 EC2
5.2.2 加入 EKS 叢集，執行 Amazon VPC CNI plugin 的EC2
5.3 Amazon VPC CNI plugin 的啟動流程
5.4 是誰安裝了 VPC CNI plugin
5.5 總結
CHAPTER 6 為什麼 CoreDNS 可以解析 VPC 內的域名及外部域名
6.1 kubelet 設定檔
6.2 Pod's DNS Policy
6.3 驗證 EKS 叢集內 DNS 解析流程
6.3.1 預設 Pod dnsPolicy 設定
6.3.2 從 Pod 內發送 DNS 請求
6.3.3 CoreDNS Pod 本身的 dnsPolicy 設定
6.4 EKS 叢集內 DNS 請求流程
6.5 結論
CHAPTER 7 為什麼 EKS add-on 可以管理 Kubernetes plugin
7.1 更新 Amazon VPC CNI plugin 為 EKS add-ons
7.2 Server-Side Apply
7.3 驗證 EKS 叢集 add-ons 使用 Server-Side Apply
7.3.1 第一次 eksctl create addon
7.3.2 第二次eksctl create addon 使用參數–force
7.4 managedFields
7.4.1 Fully managed：所有 Field Management 指定了 f: 但沒有 k:，則代表 Fully managed，任何修改都會造成衝突
7.4.2 Partially managed：如果 Field Management key 有指定值，修改 key 則會造成衝突
7.5 總結
CHAPTER 8 為什麼 EKS 叢集可以讓 Pod 部署至 Fargate
8.1 建立測試 Pod 於 Fargate 環境上
8.2 驗證部署至 EC2 工作節點與 Fargate 的 Pod 差異
8.3 驗證控制平面記錄檔（一）
8.4 什麼是 Mutate webhook
8.5 0500-amazon-eks-fargate-mutation.amazonaws.com 是怎麼來的
8.6 驗證控制平面記錄檔（二）
8.7 總結
CHAPTER 9 為什麼 EKS 能將 IAM roles 與 Kubernetes service accounts 整合（IAM roles for service accounts, IRSA）
9.1 建立使用 IRSA 的 Pod
9.2 IAM、OpenID Connect（OIDC）和 Kubernetes 關係
9.2.1 IAM 與 OpenID Connect（OIDC）
9.2.2 OpenID Connect（OIDC）與 Kubernetes
9.3 驗證 IRSA 流程
9.3.1 驗證EKS 叢集API server 設定IAM OIDC 作為identity provider
9.3.2 驗證Pod 經webhook mutate
9.3.3 Pod 掛載 OIDC JWT token
9.3.4 OIDC JWT 與 STS 驗證流程
9.4 總結
CHAPTER 10 為什麼 Managed node groups 可以保持應用程式可用性
10.1 實驗（一）
10.1.1 建立 Managed node groups 及 Self-managed node groups
10.1.2 比對 Label 的差異
10.1.3 比對 kubelet systemd unit 設定檔差異
10.1.4 比對 user-data 來源
10.1.5 為什麼兩種 node group 都可以自動加入 EKS 叢集
10.2 實驗（二）
10.2.1 建立Kubernetes Deployment object 並終止其中一Managed 節點
10.2.2 驗證 managed node group 行為
10.2.3 為什麼不是使用 eksctl 命令 scale in，而是使用ASG 命令與 managed node group 互通 ？
10.2.4 ASG lifecycle hook
CHAPTER 11 為什麼透過 CloudFormation template 建立的 self-managed node group 無法自動加入至叢集
11.1 CloudFormation template
CHAPTER 12 為什麼 CDK 部署 EKS 叢集會比較慢
12.1 建立環境 - 透過 CDK 建置 EKS 叢集
12.2 分析
12.3 總結
CHAPTER 13 為什麼 Fluent Bit/Fluentd 可以收集 EKS 叢集 Pod 以及節點記錄檔
13.1 常見 Kubernetes 記錄檔架構
13.1.1 節點層級
13.1.2 叢集層級記錄檔架構
13.1.3 直接從應用程式上傳記錄檔
13.2 以CloudWatch Agent for Container Insights Kubernetes Monitoring 為例
13.2.1 為什麼收集/var/log/containers/
13.2.2 CloudWatch Agent
13.3 建置環境
13.4 驗證
13.4.1 驗證 CloudWatch Agent 及指標
CHAPTER 14 為什麼 Container insight 指標 node_network_total_bytes 與 EC2 指標 NetworkIn/NetworkOut 不一致
14.1 建置環境
14.2 驗證
14.3 指標定義
14.4 網路封包流向
14.5 總結
CHAPTER 15 為什麼 EKS 工作節點容易佔用 IP 導致 subnets IP 位址不夠
15.1 檢視測試叢集環境
15.2 每個 Instance Type 能關聯的 ENI 數量及 IP 數量上限
15.3 預設Amazon VPC CNI plugin 的行為：多建一個ENI，關聯數個IP 位址
15.4 WARM_ENI_TARGET、WARM_IP_TARGET 及MINIMUM_ IP_TARGET 環境變數
15.5 監控
15.6 總結
CHAPTER 16 為什麼 security group 可以關聯至單獨的 EKS Pod - Security groups for pods
16.1 建置環境
16.2 SGFP 流程
16.2.1 VPC interface trunking
16.3 驗證 SGFP 流程
16.3.1 vpc-resource-mutating-webhook 是怎麼來的
16.3.2 驗證節點由 VPC resource controller 更新節點 label
16.3.3 驗證 Pod 經 webhook mutate
16.3.4 驗證節點使用 vlan 路由規則
16.3.5 驗證 branch ENI 及 trunk ENI 建立時間
16.4 總結
CHAPTER 17 為什麼使用 SGFP 使用 liveness/readiness probes 需要設定環境變數DISABLE_TCP_EARLY_DEMUX
17.1 環境變數 DISABLE_TCP_EARLY_DEMUX
17.2 TCP Early Demux 的行為
17.3 問題
17.4 總結
CHAPTER 18 為什麼 EKS 使用 NLB 作為 Kubernetes service 會遇到 connection timeout
18.1 建立測試環境
18.2 EKS 如何註冊Target Group 至Service
18.3 封包從 Pod 經由節點至 NLB 路徑
18.4 分析封包
18.5 NLB client 保留 IP 問題
18.6 替代方案
CHAPTER 19 為什麼 EKS 在更新 Kubernetes Deployment 時會有 HTTP 502 錯誤
19.1 建立環境
19.2 更新 image 流程中發生了什麼事
19.3 Kubernetes Service 與 Pod 流程
19.4 為什麼會有 HTTP 502 錯誤
19.5 如何避免問題
19.5.1 preStop hook
19.5.2 terminationGracePeriodSeconds
19.6 Pod Readiness Gates
19.7 總結
CHAPTER 20 為什麼 EKS 控制平面可以升級而無停機時間
20.1 建立環境
20.1.1 健康檢查 script
20.2 驗證
20.2.1 Pod aws-cli 記錄檔
20.2.2 控制平面記錄檔
20.2.3 CloudTrail 記錄
20.3 EKS 控制平面架構
20.4 流程
20.4.1 為什麼會有 connection timeout 錯誤
附件 參考文件
0.1 誰適合本書
0.2 本書內容
0.2.1 會包括以下內容
0.2.2 你需要準備什麼？
0.3 如何使用這本書
0.4 「為什麼」這麼重要
0.5 實務操作
CHAPTER 1 建立 EKS 叢集環境
1.1 版本
1.2 建立環境
1.3 其它方便的設定
CHAPTER 2 CloudWatch Logs 及 CloudWatch Logs Insights 簡介
2.1 CloudWatch Logs 服務專有名詞
2.2 CloudWatch Logs Insights 查詢語法
2.2.1 CloudWatch 控制台
2.2.2 AWS CLI 命令
CHAPTER 3 為什麼 kubectl可以存取 EKS 叢集
3.1 叢集身分驗證
3.2 AWS IAM Authenticator for Kubernetes
3.3 驗證EKS 叢集預設使用AWS IAM Authenticator for Kubernetes
3.3.1 kubectl
3.3.2 驗證控制平面記錄檔
3.3.3 aws-iam-authenticator server 原始碼
3.4 流程
CHAPTER 4 為什麼 EKS 工作節點可以自動加入 EKS 叢集
4.1 EKS node group
4.2 Amazon EKS optimized Amazon Linux AMIs
4.3 kubelet 啟動程序（bootstrap） 初始化步驟
4.4 驗證 kubelet TLS bootstrapping 及自動化核准發證設定
4.4.1 kubelet 設定檔
4.4.2 kube-apiserver
4.4.3 kube-controller-manager
4.4.4 建立一個 EKS 節點
CHAPTER 5 為什麼 EKS 叢集可以識別預設 CNI plugin 為 Amazon VPC CNI plugin
5.1 工作節點 - kubelet 及 CNI
5.1.1 Kubernetes 1.22 版本
5.1.2 Kubernetes 1.27 版本
5.2 驗證EKS-optimized AMI 是否預設設定Amazon VPC CNI plugin 設定檔案
5.2.1 未加入 EKS 叢集 EC2
5.2.2 加入 EKS 叢集，執行 Amazon VPC CNI plugin 的EC2
5.3 Amazon VPC CNI plugin 的啟動流程
5.4 是誰安裝了 VPC CNI plugin
5.5 總結
CHAPTER 6 為什麼 CoreDNS 可以解析 VPC 內的域名及外部域名
6.1 kubelet 設定檔
6.2 Pod's DNS Policy
6.3 驗證 EKS 叢集內 DNS 解析流程
6.3.1 預設 Pod dnsPolicy 設定
6.3.2 從 Pod 內發送 DNS 請求
6.3.3 CoreDNS Pod 本身的 dnsPolicy 設定
6.4 EKS 叢集內 DNS 請求流程
6.5 結論
CHAPTER 7 為什麼 EKS add-on 可以管理 Kubernetes plugin
7.1 更新 Amazon VPC CNI plugin 為 EKS add-ons
7.2 Server-Side Apply
7.3 驗證 EKS 叢集 add-ons 使用 Server-Side Apply
7.3.1 第一次 eksctl create addon
7.3.2 第二次eksctl create addon 使用參數–force
7.4 managedFields
7.4.1 Fully managed：所有 Field Management 指定了 f: 但沒有 k:，則代表 Fully managed，任何修改都會造成衝突
7.4.2 Partially managed：如果 Field Management key 有指定值，修改 key 則會造成衝突
7.5 總結
CHAPTER 8 為什麼 EKS 叢集可以讓 Pod 部署至 Fargate
8.1 建立測試 Pod 於 Fargate 環境上
8.2 驗證部署至 EC2 工作節點與 Fargate 的 Pod 差異
8.3 驗證控制平面記錄檔（一）
8.4 什麼是 Mutate webhook
8.5 0500-amazon-eks-fargate-mutation.amazonaws.com 是怎麼來的
8.6 驗證控制平面記錄檔（二）
8.7 總結
CHAPTER 9 為什麼 EKS 能將 IAM roles 與 Kubernetes service accounts 整合（IAM roles for service accounts, IRSA）
9.1 建立使用 IRSA 的 Pod
9.2 IAM、OpenID Connect（OIDC）和 Kubernetes 關係
9.2.1 IAM 與 OpenID Connect（OIDC）
9.2.2 OpenID Connect（OIDC）與 Kubernetes
9.3 驗證 IRSA 流程
9.3.1 驗證EKS 叢集API server 設定IAM OIDC 作為identity provider
9.3.2 驗證Pod 經webhook mutate
9.3.3 Pod 掛載 OIDC JWT token
9.3.4 OIDC JWT 與 STS 驗證流程
9.4 總結
CHAPTER 10 為什麼 Managed node groups 可以保持應用程式可用性
10.1 實驗（一）
10.1.1 建立 Managed node groups 及 Self-managed node groups
10.1.2 比對 Label 的差異
10.1.3 比對 kubelet systemd unit 設定檔差異
10.1.4 比對 user-data 來源
10.1.5 為什麼兩種 node group 都可以自動加入 EKS 叢集
10.2 實驗（二）
10.2.1 建立Kubernetes Deployment object 並終止其中一Managed 節點
10.2.2 驗證 managed node group 行為
10.2.3 為什麼不是使用 eksctl 命令 scale in，而是使用ASG 命令與 managed node group 互通 ？
10.2.4 ASG lifecycle hook
CHAPTER 11 為什麼透過 CloudFormation template 建立的 self-managed node group 無法自動加入至叢集
11.1 CloudFormation template
CHAPTER 12 為什麼 CDK 部署 EKS 叢集會比較慢
12.1 建立環境 - 透過 CDK 建置 EKS 叢集
12.2 分析
12.3 總結
CHAPTER 13 為什麼 Fluent Bit/Fluentd 可以收集 EKS 叢集 Pod 以及節點記錄檔
13.1 常見 Kubernetes 記錄檔架構
13.1.1 節點層級
13.1.2 叢集層級記錄檔架構
13.1.3 直接從應用程式上傳記錄檔
13.2 以CloudWatch Agent for Container Insights Kubernetes Monitoring 為例
13.2.1 為什麼收集/var/log/containers/
13.2.2 CloudWatch Agent
13.3 建置環境
13.4 驗證
13.4.1 驗證 CloudWatch Agent 及指標
CHAPTER 14 為什麼 Container insight 指標 node_network_total_bytes 與 EC2 指標 NetworkIn/NetworkOut 不一致
14.1 建置環境
14.2 驗證
14.3 指標定義
14.4 網路封包流向
14.5 總結
CHAPTER 15 為什麼 EKS 工作節點容易佔用 IP 導致 subnets IP 位址不夠
15.1 檢視測試叢集環境
15.2 每個 Instance Type 能關聯的 ENI 數量及 IP 數量上限
15.3 預設Amazon VPC CNI plugin 的行為：多建一個ENI，關聯數個IP 位址
15.4 WARM_ENI_TARGET、WARM_IP_TARGET 及MINIMUM_ IP_TARGET 環境變數
15.5 監控
15.6 總結
CHAPTER 16 為什麼 security group 可以關聯至單獨的 EKS Pod - Security groups for pods
16.1 建置環境
16.2 SGFP 流程
16.2.1 VPC interface trunking
16.3 驗證 SGFP 流程
16.3.1 vpc-resource-mutating-webhook 是怎麼來的
16.3.2 驗證節點由 VPC resource controller 更新節點 label
16.3.3 驗證 Pod 經 webhook mutate
16.3.4 驗證節點使用 vlan 路由規則
16.3.5 驗證 branch ENI 及 trunk ENI 建立時間
16.4 總結
CHAPTER 17 為什麼使用 SGFP 使用 liveness/readiness probes 需要設定環境變數DISABLE_TCP_EARLY_DEMUX
17.1 環境變數 DISABLE_TCP_EARLY_DEMUX
17.2 TCP Early Demux 的行為
17.3 問題
17.4 總結
CHAPTER 18 為什麼 EKS 使用 NLB 作為 Kubernetes service 會遇到 connection timeout
18.1 建立測試環境
18.2 EKS 如何註冊Target Group 至Service
18.3 封包從 Pod 經由節點至 NLB 路徑
18.4 分析封包
18.5 NLB client 保留 IP 問題
18.6 替代方案
CHAPTER 19 為什麼 EKS 在更新 Kubernetes Deployment 時會有 HTTP 502 錯誤
19.1 建立環境
19.2 更新 image 流程中發生了什麼事
19.3 Kubernetes Service 與 Pod 流程
19.4 為什麼會有 HTTP 502 錯誤
19.5 如何避免問題
19.5.1 preStop hook
19.5.2 terminationGracePeriodSeconds
19.6 Pod Readiness Gates
19.7 總結
CHAPTER 20 為什麼 EKS 控制平面可以升級而無停機時間
20.1 建立環境
20.1.1 健康檢查 script
20.2 驗證
20.2.1 Pod aws-cli 記錄檔
20.2.2 控制平面記錄檔
20.2.3 CloudTrail 記錄
20.3 EKS 控制平面架構
20.4 流程
20.4.1 為什麼會有 connection timeout 錯誤
附件 參考文件
作者介紹
王茂林（Mao-Lin Wang/focaaby）
曾擔任過 DevOps 工程師及 AWS Cloud Support Engineer，並獲取 AWS EKS 服務 Subject-matter expert 認證。近年來專注於網路、容器化及 Kubernetes 雲端原生技術。
體會AWS 環境疊加Kubernetes 複雜環境學習不易，期望分享 Kubernetes 於雲端環境相關知識，提供更多資源以降低於 Kubernetes 的門檻。
曾擔任過 DevOps 工程師及 AWS Cloud Support Engineer，並獲取 AWS EKS 服務 Subject-matter expert 認證。近年來專注於網路、容器化及 Kubernetes 雲端原生技術。
體會AWS 環境疊加Kubernetes 複雜環境學習不易，期望分享 Kubernetes 於雲端環境相關知識，提供更多資源以降低於 Kubernetes 的門檻。
規格
誠品貨碼 / 2682515487002
ISBN13 / 9786263337145
ISBN10 /
EAN貨碼 / 9786263337145
頁數 / 320
裝訂 / S:軟精裝
語言 / 1:中文/繁體
尺寸 / 17x23x2.4
級別 / N:無
退貨說明
退貨須知：
- 依照消費者保護法的規定，您享有商品貨到次日起七天猶豫期(含例假日)的權益(請注意！猶豫期非試用期)，辦理退貨之商品必須是全新狀態(不得有刮傷、破損、受潮)且需完整(包含全部商品、配件、原廠內外包裝、贈品及所有附隨文件或資料的完整性等)。
- 請您以送貨廠商使用之包裝紙箱將退貨商品包裝妥當，若原紙箱已遺失，請另使用其他紙箱包覆於商品原廠包裝之外，切勿直接於原廠包裝上黏貼紙張或書寫文字。若原廠包裝損毀將可能被認定為已逾越檢查商品之必要程度，本公司得依毀損程度扣除回復原狀必要費用(整新費)後退費；請您先確認商品正確、外觀可接受，再行拆封，以免影響您的權利；若為產品瑕疵，本公司接受退貨。
依「通訊交易解除權合理例外情事適用準則」，下列商品不適用七日猶豫期，除產品本身有瑕疵外，不接受退貨：
- 易於腐敗、保存期限較短或解約時即將逾期。(如:生鮮蔬果、乳製品、冷凍冷藏食材、蛋糕)
- 依消費者要求所為之客製化給付。(如:客製印章、鋼筆刻字)
- 報紙、期刊或雜誌。
- 經消費者拆封之影音商品或電腦軟體。
- 非以有形媒介提供之數位內容或一經提供即為完成之線上服務，經消費者事先同意始提供。(如:電子書)
- 已拆封之個人衛生用品。(如:內衣褲、襪類、褲襪、刮鬍刀、除毛刀等貼身用品)
- 國際航空客運服務。
若您退貨時有下列情形，可能被認定已逾越檢查商品之必要程度而須負擔為回復原狀必要費用(整新費)，或影響您的退貨權利，請您在拆封前決定是否要退貨：
- 以數位或電磁紀錄形式儲存或著作權相關之商品(包含但不限於CD、VCD、DVD、電腦軟體等) 包裝已拆封者(除運送用之包裝以外)。
- 耗材(包含但不限於墨水匣、碳粉匣、紙張、筆類墨水、清潔劑補充包等)之商品包裝已拆封者(除運送用之包裝以外)。
- 衣飾鞋類/寢具/織品(包含但不限於衣褲、鞋子、襪子、泳裝、床單、被套、填充玩具)或之商品缺件(含購買商品、附件、內外包裝、贈品等)或經剪標或下水或商品有不可回復之髒污或磨損痕跡。
- 食品、美容/保養用品、內衣褲等消耗性或個人衛生用品、商品銷售頁面上特別載明之商品已拆封者(除運送用之包裝外一切包裝、包括但不限於瓶蓋、封口、封膜等接觸商品內容之包裝部分)或已非全新狀態(外觀有刮傷、破損、受潮等)與包裝不完整(缺少商品、附件、原廠外盒、保護袋、配件紙箱、保麗龍、隨貨文件、贈品等)。
- 家電、3C、畫作、電子閱讀器等商品，除商品本身有瑕疵外，退回之商品已拆封(除運送用之包裝外一切包裝、包括但不限於封膜等接觸商品內容之包裝部分、移除封條、拆除吊牌、拆除貼膠或標籤等情形)或已非全新狀態(外觀有刮傷、破損、受潮等)與包裝不完整(缺少商品、附件、原廠外盒、保護袋、配件紙箱、保麗龍、隨貨文件、贈品等)。
- 退貨程序請參閱【客服專區→常見問題→誠品線上退貨退款】之說明。
付款/配送