前言

目前公司的專案大量使用 Github Action 跑自動化 CI/CD 的 pipelines 去部署服務到 AWS 環境，近期將原本 CI/CD pipelines 上與 AWS service 驗證的 workflows 做調整，驗證方式從原本藉由 IAM User 進行 assume role 的方式改成透過 AWS ODIC 的方式完成。

相較於使用 IAM user 的 secrets 驗證，OIDC 的作法能幫助我們省去管理金鑰的麻煩。

本文會 AWS 作為 cloud provider，設定方法也是以 AWS 為範例，以下內容建議有 GitHub Action 及 AWS IAM 這兩項先備知識比較能理解。

前言

上篇談到 Daemonset, StatefulSet 兩種 Pod controller，本篇將會探討 Kubernetes 一次性的運算單元 - Job/CronJob

Job/CronJob 的命名跟先前已經不同，因為是一次性的運算，以 Job 為基本單元，已經沒有任何 Set 概念，在正式討論 Job/CronJob 之前，先了解到應用程式的生命週期分兩大類：

• 不會結束 e.g. 持續運行的 Daemon
  前述提到的 DeamonSet, StatefulSet, Deploymnet, ReplicaSet 都屬於此類型
• 會結束的 e.g. 一次性的任務
  Job, CronJob 都屬於此類一次性的運算單元

前言

上篇討論 Deployment 做滾動式部署，本篇則會接著探討另外兩種 Controller - Daemonset, StatefulSet 。

前言

上篇文章 - [Kubernetes] Kubernetes 基礎(三) Pod Controller - ReplicaSet 探討如何透過 ReplicaSet 管理多個 Pod 副本，確保 K8s 在任何時間點能保有特定數量的 Pod 於 Cluster 中運行。

本文接著討論 Pod 的另一種 Controller - Deployment

前言

上篇文章 - [Kubernetes] Kubernetes 基礎(二) Pod 操作 討論如何透過 kubectl 指令對 K8s 做一系列的操作，本篇主要記錄 Pod Controller 中的 ReplicaSet

前言

延續上一篇[Kubernetes] Kubernetes 基礎(ㄧ) 架構及元件討論 Kubernetes 的架構與元件後，接著來探討如何操作 Kubernetes 的 Pod 元件吧！

以下簡稱 Kubernetes 為 K8s。

前言

Kubernetes 是一個用於管理多個容器(containers)的大型管理平台，原先是 Google 內部自行研發的系統，後來開源出來，讓世界各地的開發者都能加入開發、優化的行列，近期工作上開始接觸 Kubernetes，藉此記錄一下學習到的知識。

前言

在資料處理的過程中，會針對資料源的不完整或是冗余的資料訂定 pipelines 來做預處理，Elastic 官方提供 elastic ingest pipeline 功能，將一連串的制定好的處理器(Processors) 匯集在一個 pipeline ，對來源資料做結構化處理。

我們可以設置多個獨立的 Processors 在同個 Pipeline 裡面，在來源資料送進 Elasticsearch 做 indexing 之前，會經過指定的 Pipeline， Pipeline 裡含有多個 Processors， Processor 可以做的事情很多，如: 重新命名、新增欄位、資料型別&大小寫轉換，甚至支援正規表達式，可以做複雜的判斷式。

本文主要示範其中一種 Processor - Enrich Processor

什麼是 Ansile?

Ansile 是由 Red Hat(紅帽) 公司所提供，經開放原始碼社群進行開發，秉持基礎設施即代碼為其中一項理念，專注在 IT 自動化領域，透過撰寫 YAML 腳本對 IT 基礎設施進行操作及管理。

主要的優點：

• 以 YML 格式編寫，容易上手與維護
• 無代理(Agentless)程式
• 透過 SSH 進行連線，用於與遠端 Server 溝通。
• 不需要安裝在 Client 端

前言

要將 Elasticsearch 內的資料做視覺化，透過 Kibana Visualization 拉圖表呈現，並整合進一張 Dashboard 中。

由於 Visualization 是對應於 Kibana 中的 index pattern，若今天把原始的 index pattern 刪除，重建一個同名的 index pattern，原始的 Visualization 會出現 Could not locate that index-pattern 這類的錯誤訊息，無法正常顯示。 如下圖所示：

原因是每個建好的 index pattern 都會帶一個獨立 ID ，Kibana Visualization 會綁定該 ID，故原始 index pattern 被刪除時，即便新建一個同名 index pattern，ID 改變造成 Visualization 找不到原始綁定的 index pattern。

本篇文章會示範如何在不另外建 Visualization 和 Dashboard 的情況下，替換新的 Index Pattern