DEV Community: 8P Inc.

Kiro Cannot Get Response from The Second Command in The Same Shell

8P Inc. — Sat, 20 Sep 2025 09:15:48 +0000

As you may know, when Kiro wants to run shell commands, it opens a new zsh (named "Kiro"), runs the command on that shell, and gets the response to analyze the next step.

Unfortunately, if you're using Kiro, zsh, and powerlevel10k theme in OH-My-Zsh together, you may face this problem like I did.

For the first command sent to the shell, it gets a response successfully. However, for the second command in the same shell, Kiro cannot get the response from the shell command and ends up waiting for a response indefinitely.

This problem is so annoying and made me fed up with Kiro.

Recently, I discovered it's due to the incompatibility between powerlevel10k theme and Kiro. So, I found a way to mitigate this problem, which allows me to give Kiro another shot.

We know that:

If zsh is opened by Kiro, the environment variable TERM_PROGRAM equals "kiro"
There are 2 personas in Kiro that can open new shells:
- "Us" as users can use powerlevel10k theme
- "Kiro" as an IDE can't use powerlevel10k theme

The Mitigation:

Key Concept: We will not use powerlevel10k theme if the zsh is opened by Kiro

In Kiro, add environment variable ENABLE_ZSH_THEME=1 in zsh configuration
- Edit Kiro settings
- Change this value (terminal.integrated.profiles.osx)
- Add environment variable At this stage, zsh opened by you will have environment variable ENABLE_ZSH_THEME=1, while zsh opened by Kiro will not have ENABLE_ZSH_THEME=1
Configure ~/.zshrc to match the configuration above
- Add a condition to load powerlevel10k theme
Test by opening zsh yourself and letting Kiro open it to see the result

Expected Result:

zsh opened by Kiro → no powerlevel10k theme

zsh opened by You → has powerlevel10k theme

Benefits

✅ Kiro commands work reliably without timeouts
✅ Preserves your beautiful terminal theme for regular use**
✅ Simple, maintainable solution with minimal configuration
✅ No need to completely disable powerlevel10k

เริ่มต้นใช้งาน Amazon Q Developer Custom Agents

8P Inc. — Sun, 03 Aug 2025 04:07:15 +0000

หลายคนที่ได้ลองใช้ Amazon Q Developer น่าจะหงุดหงิดของ /profile เพราะมันดันไม่สามารถ custom พวก MCP configuration ได้ และไม่สามารถ set trust tools ตามแต่ละ profile ได้
ตอนนี้ AWS เลยทำการ rebrand /profile ไปเป็น feature ใหม่ที่เรียกว่า custom agents

คราวนี้เรามาดูกันครับว่า custom agents มีอะไรให้เราเล่นบ้าง

Migrate

เริ่มจากการ migrate ก่อน ปกติ Q cli จะถามว่าเราจะ upgrade ไหม แต่ถ้าไม่ถาม หรือว่าเรา say no ไปก็ run command นี้ เพื่อ migrate ได้

q agent migrate --force

ถ้าใครอยากลงลึกเรียนเชิญ -> Migrate Profiles to Agents

Customize Agents

หลังจากที่ migrate แล้ว profile ที่เรา set ไว้มันจะกลายเป็น agent ให้เราโดยอัตโนมัติ โดยกลายเป็น json configuration file ใน path ~/.aws/amazonq/cli-agents/<NAME>.json

AWS มี plan ที่จะเพิ่ม sub command /agent edit <NAME> ให้ แต่ ณ วันที่เขียน blog นี้ยังไม่มี แต่เราสามารถ edit file นี้ได้ตรงๆ ผ่าน ide ได้ตามปกติ

ที่นี้มาดูหน้่าตาของ configuration file ( สามารถพิมพ์ /agent schema เพื่อดู schema เต็มๆ ของ config ได้ )

{
  "name": "<NAME>",
  "description": "",
  "prompt": null,
  "mcpServers": {},
  "tools": [
    "*"
  ],
  "toolAliases": {},
  "allowedTools": [
    "fs_read"
  ],
  "resources": [
    "file://AmazonQ.md",
    "file://README.md",
    "file://.amazonq/rules/**/*.md"
  ],
  "hooks": {},
  "toolsSettings": {},
  "useLegacyMcpJson": true
}

name คือ ชื่อของ custom agent ควรตรงกับ ชื่อ file เพื่อความไม่สับสน โดย Q cli จะอ้างอิงชื่อ custom agent จากในส่วนนี้
description คือ คำอธิายคร่าวๆ ของ custom agent นี้
prompt คือที่ใส่ system prompt ของ custom agent นี้
mcpServers คือ ที่ configure mcp server ที่ agent นี้จะ start ขึ้นมาพร้อมกับ custom agent
tools ใช้ระบุ tools ต่างๆ ที่ custom agent นี้สามารถใช้ได้ สามารถระบุได้ทั้ง builtin tools และ tools จาก mcp server
toolAliases ใช้ตั้งชื่อ tools ที่มีอยู่แล้วใหม่ ให้เป็นแบบที่เข้าใจง่ายขึ้น หรือ จำง่ายขึ้น
allowedTools ใช้ระบุว่า เมื่อ Q cli ถูก start ขึ้นมาให้ trust tools ไหนได้เลย
- โดยสามารถ allow ได้ทั้งแบบ
  - ระบุ built-in tools -> fs_read
  - ทั้ง mcp server -> @server_name
  - เฉพาะบาง tools ใน mcp server -> @server_name/tool_name
  - ทั้งหมด -> *
  - builtin ทั้งหมด -> @builtin

   {
     "allowedTools": [
       "fs_read",
       "@git/git_status",
       "@fetch"
     ]
   }

resources ใช้ระบุถึง context file ของ custom agent นั้นๆ เป็น concept เดียวกับ /context ที่ใช้ร่วมกับ /profile
hooks เป็นที่ที่เราสามารถ define ได้ว่า ใน event เหล่านี้ จะให้ Q cli ทำอะไร โดย ตอนนี้มี 2 events คือ
- agentSpawn: ตอนที่ Q cli ถูก start
- userPromptSubmit: ตอนที่เรา submit prompt ให้ Q cli

{
  "hooks": {
    "agentSpawn": [
      {
        "command": "git status",
      }
    ],
    "userPromptSubmit": [
      {
        "command": "ls -la",
      }
    ]
  }
}

toolsSettings ใช้ define configuration ต่างๆ ของ builtin tools เช่น

   {
     "toolsSettings": {
       "fs_write": {
         "allowedPaths": ["src/**", "tests/**"]
       },
       "execute_bash": {
         "allowedCommands": ["git status", "npm test"],
         "allowReadOnly": true
       },
       "use_aws": {
         "allowedServices": ["s3", "lambda", "ec2"]
       }
     }
   }

useLegacyMcpJson ระบุว่าจะให้ include legacy global MCP configuration file (~/.aws/amazonq/mcp.json) เข้ามาด้วยไหมตอน Q cli ถุก start

สามารถดูเพิ่มเติมได้จาก Agent Configuration Format

Validate Agent Configuration

q agent validate --path ./my-agent.json

ถ้า syntax ผิดจะเป็นประมาณนี้

แต่ถ้าถูกจะไม่มีอะไร print ออกมา และ exit 0

Use Custom Agent

เราสามารถ lists agent ทั้งหมดที่เรามีได้โดย

q agent list

[default]> /agent list

จากนั้นเรียกใช้ custom agent ดังนี้

q chat --agent <NAME>

ในอนาคต เราจะสามารถ switch custom agent ได้ด้วย /agent use <NAME> ซึ่งเป็น feature ที่กำลัง develop อยู่

Set Default Agent

เมื่อเราสร้าง custom agent แล้วสามารถ set ให้มันเป็น ค่า default ได้โดย

q agent set-default --name <NAME>

/agent set-default --name <NAME>

จากนั้นเราสามารถเรียกใช้ custom agent ได้ โดยการเรียก q หรือ q chat ได้โดยไม่ต้องระบุชื่อ custom agent แล้ว

ถ้าเราไม่ได้ set default agent ไว้ Q cli จะใช้งาน builtin default agent ในการทำงาน เช่นเดียวกันถ้า configuration ของ custom agent เราผิด เวลาเรา start Q cli มันก็จะ fall back มาใช้งาน builtin default agent เหมือนกัน

Type of Custom Agent Configuration

มีอยู่ 2 แบบ ดังนี้

Local custom agent (Workspace-specific)
- Path: {current_working_directory}/.amazonq/cli-agents/
- Scope: จะใช้ได้ก็ต่อเมื่อ start Q cli ใน {current_working_directory}
- Use Case: Project-specific agents หรือ team-shared configurations
- Example:

my-project/
├── .amazonq/
│   └── cli-agents/
│       ├── dev-agent.json
│       ├── aws-specialist.json
│       └── code-reviewer.json
├── src/
│   └── main.py
└── README.md

Global custom agent
- Path: ~/.aws/amazonq/cli-agents/
- Scope: start Q cli ได้ทุกที่
- Use Case: agents ส่วนตัว หรือ ใช้เป็น general-purpose assistants
- Example

~/.aws/amazonq/cli-agents/
├── general-assistant.json
├── documentation-writer.json
├── security-analyst.json
└── devops-automation.json

ถ้าเราอยู่ที่ {current_working_directory} แล้ว list agents จะเห็นแบบนี้

> q agent list
general-assistant        /Users/demo/.aws/amazonq/cli-agents
documentation-writer     /Users/demo/.aws/amazonq/cli-agents
security-analyst         /Users/demo/.aws/amazonq/cli-agents
devops-automation        /Users/demo/.aws/amazonq/cli-agents
dev-agent                /Users/demo/my-project/.amazonq/cli-agents
aws-specialist           /Users/demo/my-project/.amazonq/cli-agents
code-reviewer            /Users/demo/my-project/.amazonq/cli-agents

[general-assistant] > /agent list

* general-assistant   
  documentation-writer
  security-analyst    
  devops-automation               
  dev-agent           
  aws-specialist      
  code-reviewer

ถ้าออกไป directory อื่น ก็จะเห็น custom agent เท่าที่มีใน Global

> q agent list
general-assistant        /Users/demo/.aws/amazonq/cli-agents
documentation-writer     /Users/demo/.aws/amazonq/cli-agents
security-analyst         /Users/demo/.aws/amazonq/cli-agents
devops-automation        /Users/demo/.aws/amazonq/cli-agents

[general-assistant] > /agent list

* general-assistant   
  documentation-writer
  security-analyst    
  devops-automation

How to Create AWS Builder ID

8P Inc. — Sun, 06 Jul 2025 06:53:24 +0000

Table of Content

Create AWS Builder ID

Login with your AWS Builder ID

Register MFA Devices

Create AWS Builder ID

Go to AWS Builder ID profile. You will redirect to "Create AWS Builder ID" page.
- If you have already had "AWS Builder ID", click "Already have AWS Builder ID? Sign in" and proceed login.

If you don't have "AWS Builder ID" yet, fill in your email ( recommend to use personal email since. You can use this ID to register for AWS Certificate Exam and AWS Skill Builder in the future.

To continue creating "AWS Builder ID", fill in your name and click Next

The verification code will be sent to you email address.

Fill in the code and click Verify

After your email is successfully verified, it will direct you to set password for your account. Fill in your password, finish captcha challenge and click Create AWS Builder ID

After your AWS Builder ID is successfully created, it will redirect you to main login page.

Login with your AWS Builder ID

Click at "Already have AWS Builder ID? Sign in" and fill in your email

Fill in your password and enter captcha

The verification code will be sent to you email address.

Fill in the code and click Verify

It will direct you back to login page

Register MFA Devices

Wait for about 10 minutes after creating AWS Builder ID to continue add MFA devices

Go to AWS Builder ID profile and login with your credential. After login success, you will be direct to this page

Click at Security and Register devices

Select your preference MFA devices type and click Next.

Follow its instruction to add each type of MFA device. After successfully add a MFA devices, your device will be appeared here.

Open Incognito or InPrivate mode, and try login to AWS Builder ID profile. You will be ask for both password and MFA device. After successfully login, sign out and close the Incognito or InPrivate mode.

After finish all the steps, your AWS Builder ID is ready and safe to use.

References

Create your AWS Builder ID

GitHub Self-Hosted Runners on Azure Container Apps with Autocsaling

8P Inc. — Tue, 07 Mar 2023 04:41:00 +0000

เรื่องมันมีอยู่ว่า อยากได้ GitHub Self-Hosted Runners แบบที่ autoscale ได้ตาม workload ครับ และตอนที่ไม่ใช้เลยก็สามารถ scale in instance เหลือ 0 ได้ ผมค้นไปเจอ Autoscaling self hosted GitHub runner containers with Azure Container Apps (ACA) มา คิดว่าค่อนข้างตรงกับที่ต้องการ เลยเอามาลอง POC ดูครับ

จากใน link ข้างต้น จะเป็นการ run container image ของ GitHub Self-Hosted Runners ด้วย Azure Container Apps และอาศัยความสามารถของ KEDA autoscaler ในการ scale replica ตามจำนวน queue ใน Azure Storage Queue

การทำงานจะเป็นแบบนี้ครับ

เมื่อ GitHub workflow ถูก trigger ให้ run มันจะไป push message ลงไปที่ Azure Storage Queue
KEDA scaler ใน Azure Container Apps ตรวจพบว่ามี queue เพิ่มขึ้น จึงทำการ scale out instance ของ GitHub selfhosted runners ตามจำนวน queue
เมื่อ scale เรียบร้อย ตัว GitHub selfhosted runners จะมารับงานจาก GitHub workflow ไป run จนเรียบร้อย
GitHub workflow ทำการ delete message ออกจาก Azure Storage Queue
KEDA scaler ตรวจพบว่ามี queue ลดลงจึง scale in instance ของ GitHub selfhosted runners ลง ถ้า queue เป็น 0 จำนวน instance ของ GitHub selfhosted runners ก็เป็น 0

ด้วยความคัน ผมจะเปลี่ยนนิดหน่อย ดังนี้

ใช้เป็น Azure Service Bus Queue แทน Azure Storage Queue เพราะในกรณีที่มีการ send / receive message เยอะ Azure Service Bus Queue จะถูกกว่านิดหน่อย (อ่านเพิ่ม Storage queues and Service Bus queues - compared and contrasted)
ปรับ workflow ให้ใช้ Workload Identity Federation เพื่อให้เป็น passwordless
สร้าง Azure Container Apps แบบมี Virtual Network Integration เพื่อให้ interact กับ resources ที่เป็น private ได้

Diagram จะเป็นแบบนี้นะครับ

และเช่นกัน ณ เวลาที่ผมเขียน blog นี้นั้น Azure Container Apps ยังมีข้อจำกัดดังนี้

Support แค่ Linux-based x86-64 (linux/amd64) container image.
ยังไม่มี KEDA scalers for GitHub runners
ยังไม่มีที่ Southeast Asia

ทีนี้ก่อนเริ่มทำเรามาดูกันก่อนว่าเราต้องมีอะไรกันบ้าง

Azure Subscription ( ใช้เพื่อ deploy resources ต่างๆ เช่น vnet, log analytics workspace, container apps และ service bus เป็นต้น )
Github Organization ( เราจะให้ runners เป็น oganization level runners )
Github Repository ( ใช้เก็บและ run workflow )

ลงมือทำกันเลย

Prerequisites

Create Azure subscription
Sign up Github
Create repository
Create organization
Create Github Access Token โดยเลือก scope เป็น admin:org
Create GitHub Self-hosted Runners Container Image ดูได้จาก docker-github-actions-runner หรือ Create a Docker based Self Hosted GitHub runner Linux container แล้ว push ขึ้น container registry ของเรา

Preflight

ทำการ install extensions ของ Azure CLI และ providers ที่ subscription

az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.ServiceBus

Define variables

POC_PREFIX="pocghaca"
LOCATION="westus3"
LOC="usw3"
RESOURCE_GROUP="rg-${POC_PREFIX}-az-${LOC}-001"
VNET_NAME="vnet-${POC_PREFIX}-az-${LOC}-001"
INFRASTRUCTURE_SUBNET="snet-infra-az-${LOC}-001"
LOG_ANALYTIC_WORKSPACE="log-${POC_PREFIX}-az-${LOC}-001"
SERVICEBUS_NAME="sbn-${POC_PREFIX}-az-${LOC}-001"
SERVICEBUS_QUEUE="gh-runner-scaler"
CONTAINERAPPS_ENVIRONMENT="cte-${POC_PREFIX}-az-${LOC}-001"
CONTAINERAPP_NAME="cta-${POC_PREFIX}-az-${LOC}-001"
CONTAINER_REGISTRY_SERVER="..<YOUR-CONTAINER-REGISTRY>.."
CONTAINER_REGISTRY_USER="..<YOUR-REGISTRY-USERNAME>.."
CONTAINER_REGISTRY_PASS="..<YOUR-REGISTRY-PASSWORD>.."
CONTAINER_IMAGE="..<YOU-CONTAINER-IMAGE>.."
PAT="..<YOUR-GITHUB-ACCESS-TOKEN>.."
GH_ORG="..<YOUR-ORGANIZATION-NAME>.."

Prerequisite Azure Resources

Create Resource group

az group create \
--name $RESOURCE_GROUP \
--location $LOCATION

Create Log analytics workspaces

az monitor log-analytics workspace create \
--name $LOG_ANALYTIC_WORKSPACE \
--resource-group $RESOURCE_GROUP \
--quota 1 \
--retention-time 30 \
--sku PerGB2018

Create Virtual network and subnet

az network vnet create \
--resource-group $RESOURCE_GROUP \
--name $VNET_NAME \
--location $LOCATION \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group $RESOURCE_GROUP \
--vnet-name $VNET_NAME \
--name $INFRASTRUCTURE_SUBNET \
--address-prefixes 10.0.0.0/21

Azure Service Bus and Queue

Create Azure service bus and queue

az servicebus namespace create \
--name $SERVICEBUS_NAME \
--resource-group $RESOURCE_GROUP \
--location $LOCATION
az servicebus queue create \
--resource-group $RESOURCE_GROUP \
--namespace-name $SERVICEBUS_NAME \
--name $SERVICEBUS_QUEUE

Create connection string of Azure Service Bus Queue

az servicebus queue authorization-rule create \
--resource-group $RESOURCE_GROUP \
--namespace-name $SERVICEBUS_NAME \
--queue-name $SERVICEBUS_QUEUE \
--name $CONTAINERAPP_NAME \
--rights Manage Send Listen

Add yourself as Azure Service Bus Data Owner on Azure Service Bus Namespace

Test send a message and receive/delete a message from the queue

⚠️ ถ้าทำใน bash ของ Azure Cloud Shell ใน run az login อีกครั้ง

# Send message
az rest \
--resource "https://servicebus.azure.net" \
--method post \
--headers BrokerProperties='{"TimeToLive":10}' \
--url "https://${SERVICEBUS_NAME}.servicebus.windows.net/${SERVICEBUS_QUEUE}/messages" \
--body "Hello from Az REST with TTL"

# Receive / Delete message
az rest \
--resource "https://servicebus.azure.net" \
--method delete \
--url "https://${SERVICEBUS_NAME}.servicebus.windows.net/${SERVICEBUS_QUEUE}/messages/head"

Create Azure Container App

รวบรวมข้อมูลที่ใช้ในการสร้าง Azure Container App และ Azure Container Environment

INFRASTRUCTURE_SUBNET=$(az network vnet subnet show --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --name $INFRASTRUCTURE_SUBNET --query "id" -o tsv | tr -d '[:space:]')
LOG_WORKSPACE_ID=$(az monitor log-analytics workspace show --name $LOG_ANALYTIC_WORKSPACE --resource-group $RESOURCE_GROUP --query "customerId" -o tsv | tr -d '[:space:]')
LOG_WORKSPACE_KEY=$(az monitor log-analytics workspace get-shared-keys --name $LOG_ANALYTIC_WORKSPACE --resource-group $RESOURCE_GROUP --query "primarySharedKey" -o tsv | tr -d '[:space:]')
CONNECTION_QUEUE=$(az servicebus queue authorization-rule keys list --resource-group $RESOURCE_GROUP --namespace-name $SERVICEBUS_NAME --queue-name $SERVICEBUS_QUEUE --name $CONTAINERAPP_NAME --query primaryConnectionString --output tsv | tr -d '[:space:]')

Create Azure Container App Environment

az containerapp env create \
  --name $CONTAINERAPPS_ENVIRONMENT \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --docker-bridge-cidr "172.17.0.1/16" \
  --platform-reserved-cidr "100.64.0.0/16" \
  --platform-reserved-dns-ip "100.64.0.10" \
  --logs-destination "log-analytics" \
  --logs-workspace-id $LOG_WORKSPACE_ID \
  --logs-workspace-key $LOG_WORKSPACE_KEY \
  --internal-only

Create Azure Container App with autoscaling

az containerapp create \
--resource-group $RESOURCE_GROUP \
--name $CONTAINERAPP_NAME \
--image $CONTAINER_IMAGE \
--environment $CONTAINERAPPS_ENVIRONMENT \
--registry-server $CONTAINER_REGISTRY_SERVER \
--registry-username $CONTAINER_REGISTRY_USER \
--registry-password $CONTAINER_REGISTRY_PASS \
--secrets gh-token="$PAT" servicebus-connection-string="$CONNECTION_QUEUE" \
--env-vars \
  ACCESS_TOKEN=secretref:gh-token \
  RUNNER_SCOPE="org" \
  ORG_NAME=$GH_ORG \
  LABELS="poc-gh-aca" \
  RUNNER_WORKDIR="/tmp/github-runner" \
--cpu "1.75" \
--memory "3.5Gi" \
--min-replicas 0 \
--max-replicas 3 \
--scale-rule-auth "connection=servicebus-connection-string" \
--scale-rule-name queue-scaling \
--scale-rule-type azure-servicebus \
--scale-rule-metadata \
  "queueName=$SERVICEBUS_QUEUE" \
  "namespace=$SERVICEBUS_NAME" \
  "messageCount=1"

ตรวจสอบ system log

az containerapp logs show \
--resource-group $RESOURCE_GROUP \
--name $CONTAINERAPP_NAME \
--type console \
--follow

ตรวจสอบ console log

az containerapp logs show \
--resource-group $RESOURCE_GROUP \
--name $CONTAINERAPP_NAME \
--type system \
--follow

ตรวจสอบว่า runner เกิดขึ้นใน organization ของเรา

ลอง send และ delete message แล้วตรวจสอบ Queue ใน Azure Service Bus และ check จำนวน runner ที่เกิดขึ้นใน organization

# Send message
az rest \
--resource "https://servicebus.azure.net" \
--method post \
--headers BrokerProperties='{"TimeToLive":3600}' \
--url "https://${SERVICEBUS_NAME}.servicebus.windows.net/${SERVICEBUS_QUEUE}/messages" \
--body "Hello from Az REST with TTL"

# Receive / Delete message
az rest \
--resource "https://servicebus.azure.net" \
--method delete \
--url "https://${SERVICEBUS_NAME}.servicebus.windows.net/${SERVICEBUS_QUEUE}/messages/head"

# See console log
az containerapp logs show \
--resource-group $RESOURCE_GROUP \
--name $CONTAINERAPP_NAME \
--type console \
--follow

# See system log
az containerapp logs show \
--resource-group $RESOURCE_GROUP \
--name $CONTAINERAPP_NAME \
--type system \
--follow

Create GitHub workflow to verify our system

ทำการ create Service Principal แล้ว federate credential ไปให้ Github Organization และ Repository ที่เราสร้างเตรียมไว้โดยเลือกเป็น branch main

รายละเอียดดูได้จาก Let Github Action Access Azure Resources without password

Create role assignment ให้ Service Principal ของเรามีสิทธิ์ Azure Service Bus Data Receiver และ Azure Service Bus Data Sender ที่ Queue ที่เราสร้างไว้

Create role assignment ให้ Service Principal ของเรามีสิทธิ์ Contributor บน subscription ของเรา

สำหรับสาย free ถ้า GitHub repository ของคุณเป็น public ต้องมา allow ที่ Runner Groups Default ก่อน

ต่อไปเข้าไปที่ Repository ของตัวเองแล้ว define secret และ variable เหล่านี้
- Secrets
  - AZURE_CLIENT_ID
  - AZURE_SUBSCRIPTION_ID
  - AZURE_TENANT_ID
- Variables
  - AZ_SERVICE_BUS_NAMESPACE
  - AZ_SERVICE_BUS_QUEUE

จากนั้นทำการสร้าง file workflow .github/workflows/demo.yaml ใน GitHub Repository

name: Scale up selfhosted runner and run
on:
   workflow_dispatch:

permissions:
  id-token: write
  contents: read

env:
  AZ_SERVICE_BUS_NAMESPACE: ${{ vars.AZ_SERVICE_BUS_NAMESPACE }}
  AZ_SERVICE_BUS_QUEUE:  ${{ vars.AZ_SERVICE_BUS_QUEUE }}

jobs:
  scale-out-runner:
    runs-on: ubuntu-latest
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: scale out self hosted
        run: |
         az rest \
         --resource "https://servicebus.azure.net" \
         --method post \
         --headers BrokerProperties='{"TimeToLive":3600}' \
         --url "https://${{ env.AZ_SERVICE_BUS_NAMESPACE }}.servicebus.windows.net/${{ env.AZ_SERVICE_BUS_QUEUE }}/messages" \
         --body "${{ github.run_id }}"

  deploy:
    runs-on: [self-hosted, poc-gh-aca]
    needs: [scale-out-runner]
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: 'Run az commands'
        run: |
          az account show --output table

  scale-in-runner:
    runs-on: ubuntu-latest
    needs: [scale-out-runner, deploy]
    if: ${{ always() && needs.scale-out-runner.result == 'success' }}
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: scale in self hosted
        run: |
          az rest \
          --resource "https://servicebus.azure.net" \
          --method delete \
          --url "https://${{ env.AZ_SERVICE_BUS_NAMESPACE }}.servicebus.windows.net/${{ env.AZ_SERVICE_BUS_QUEUE }}/messages/head"

ใน workflow จะมี 3 jobs

scale-out-runner: จะเป็นการ send message เข้าไปที่ Service Bus เพื่อ ให้ container apps scale out GitHub SelfHosted Runners ขึ้นมารับงานไปทำ
deploy: จะเป็นส่วนงานหลักที่ pipeline ต้องทำ โดย job นี้จะทำก็ต่อเมื่อ scale-out-runner success
scale-in-runner: หลังจากทำงานเสร็จไม่ว่าจะ success หรือไม่ job นี้จะทำการ delete message ออกจาก Service Bus เพื่อให้ container apps ทำการ scale in GitHub SelfHosted Runners ลงไป

ให้ลองทำการ run workflow หลายๆ ครั้ง พร้อมๆ กัน

ตรวจสอบดูว่าการ autoscale ทำงานได้ตามที่คาดการณไว้หรือไม่
- Azure Service Bus Queue
- Container App Replicas
- Github Organization-Level Self-hosted Runners
หลังจาก workflow run เรียบร้อยหมดแล้ว ลองตรวจสอบ อีกครั้ง ทุกอย่างต้องเป็น 0
- Azure Service Bus Queue
- Container App Replicas
- Github Organization-Level Self-hosted Runners

References

Let Github Action Access Azure Resources without password

8P Inc. — Tue, 03 Jan 2023 11:11:13 +0000

พอกันที่กับการ rotate secret ของ Service Principal ที่ใช้กับ Github Action ทุก 3 เดือน 6 เดือน
พอกันทีกับโอกาสที่ secret ของ Service Principal จะ leak

วันนี้มีสิ่งที่เรียกว่า "Workload Identity Federation" นำเสนอครับ

Workload Identity Federation

คือการที่เราทำการสร้าง trusted relationship กันระหว่าง Microsoft Identity Platform กับ External Identity Provider (IdP) เช่น GitHub พอ trust กันแล้ว เราจะสามารถใช้ token ของ External IdP ไปแลกเป็น access token ของ Azure เพื่อ access resources ใน Azure ที่ถูก protect ด้วย Azure AD ได้

External Identity Provider (IdP) ที่ support ตอนนี้ เช่น

GitHub Actions
Google Cloud
Workload ใน Kubernetes
External Provider อื่นๆ ที่ support OpenID Connect (OIDC)

มาดู flow ดีกว่าว่ามันทำงานยังไง

External Workload เช่น github action ทำการขอ token จาก IdP ของตัวเอง
External IdP ทำการ generate แล้วให้ token กับ External Workload
External Workload ใช้ token ที่ได้มาเพื่อขอ access token จาก Microsoft identity platform
Microsoft identity platform ทำการตรวจสอบว่ามี trust relationship สร้างไว้อยู่หรือไม่ และ เอา token ที่ได้ไป validate กับ External IdP
ถ้าทุกอย่างเรียบร้อย Microsoft identity platform จะสร้าง access token แล้วส่งให้กับ External Workload
จากนั้น External Workload จะใช้ access token ที่ได้มาเช้าถึง resources ใน Azure โดย access token จะมี permission เท่ากับ service principal ที่ สร้าง trust relationship ไว้

มาลองลงมือทำดีกว่า

สิ่งที่เราจะทำคือสร้าง

1 Github Repos ที่มี 2 Actions และ 2 environments ( develop / production )
2 services principals ( develop / production )
trust relationship ระหว่าง Service Principals และ Environment ของ Github
2 resource groups และให้ services principals เป็น Contributors ใน resource groups ( develop / production )
สร้าง Github Action Workflow เพื่อทดสอบ storage account ใน resource group ตาม environemnt

สร้าง Github Repos และ environment

สร้าง Github Action Repo

Create Environment ( ชื่อ environemnt จะถูกใช้ในการ สร้าง trust relationship ใน Azure Portal )
- develop
- production

สร้าง service principal

ใน Azure Portal > Azure Active Directory > App registrations > + New Registration

ใส่ชื่อของ service principal เลือก single tenant แล้วกด Register
- sp-demogithub-az-asse-dev-001 สำหรับ develop
- sp-demogithub-az-asse-prd-001 สำหรับ production

สร้าง Trust Relationship ( Federated credentials )

Click ที่ Service Principal ที่เราสร้างขึ้น > Certificates & secrets > Federated credentials > + Add credential

ใส่ข้อมูลของ Github Repo ที่ต้องการสร้าง Trust Relationship ด้วย
- Organization: ใส่ชื่อ organization ของ ตัวเอง
- Repository: ชื่อ repo ของ github ที่เราสร้างไว้ก่อนหน้า
- Entity type: เลือก Environment ค่าอื่นดูต่อที่ Entity type examples
- Name: ตั้งชื่อขอ Federated credentials นี้ ( FQDN friendly )

กดที่ overview ของ Service Pricipal แล้วเก็บค่าเหล่านี้ไว้ใช้ add ใน github environment
- AZURE_CLIENT_ID: Application (client) ID
- AZURE_TENANT_ID: Directory (tenant) ID
- AZURE_SUBSCRIPTION_ID: subscription ID ที่จำให้ Github Action Provision storage account

ทำแบบเดียวกันกับ Service Principal ของ Production Environment

สร้าง resource group แล้ว assign Contributor role ให้กับ Service Principal

สร้าง resource groups
- rg-demogithubfed-az-asse-dev-001 สำหรับ develop
- rg-demogithubfed-az-asse-prd-001 สำหรับ production

Create Role Assignment ให้
- sp-demogithub-az-asse-dev-001 เป็น Contributor ใน rg-demogithubfed-az-asse-dev-001

sp-demogithub-az-asse-prd-001 เป็น Contributor ใน rg-demogithubfed-az-asse-prd-001

สร้าง Github workflow เพื่อทดสอบสร้าง storage account

สร้าง Enviroment secret ใน Github
- AZURE_CLIENT_ID: Application (client) ID
- AZURE_TENANT_ID: Directory (tenant) ID
- AZURE_SUBSCRIPTION_ID: subscription ID ที่จำให้ Github Action Provision storage account

ทำแบบเดียวกัน กับ production enviroment

สร้าง Github Workflow สำหรับ create github action

Action ที่ใช้ login คือ Azure Login โดยเราจะทำตามตัวอย่างนี้ Sample workflow that uses Azure login action using OIDC to run az cli (Linux)

สร้าง file สำหรับ develop => .github/workflows/dev-demo.yml

name: DEV - Demo Azure Login with OIDC
on:
   workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: develop
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: 'Run az commands'
        run: |
          az account show --output table
          az storage account create \
          --subscription ${{ secrets.AZURE_SUBSCRIPTION_ID }} \
          --location southeastasia \
          --resource-group rg-githubfed-az-asse-dev-001 \
          --name stdemofeddev001 \
          --sku Standard_LRS \
          --default-action Deny \
          --min-tls-version TLS1_2 \
          --output table

สร้าง file สำหรับ production => .github/workflows/prd-demo.yml

name: PRD - Demo Azure Login with OIDC
on:
   workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: 'Run az commands'
        run: |
          az account show --output table
          az storage account create \
          --subscription ${{ secrets.AZURE_SUBSCRIPTION_ID }} \
          --location southeastasia \
          --resource-group rg-githubfed-az-asse-prd-001 \
          --name stdemofedprd001 \
          --sku Standard_LRS \
          --default-action Deny \
          --min-tls-version TLS1_2 \
          --output table

ทดสอบ run Github Action

ตรวจสอบ storage account ที่ Azure Portal

References

Hybrid DNS Solution with Azure

8P Inc. — Fri, 04 Nov 2022 01:07:56 +0000

หลังจากที่ Azure ประกาศ GA Azure DNS Private Resolver ก็ได้ฤกษ์ ลองเล่นซะที หลังจากเก็บไว้ในกองดองอยู่นาน มาเข้าเรื่องกันเลยครับ

Azure DNS Private Resolver คืออะไร

สั้นๆ มันคือ resource ที่ทำหน้าที่เป็น DNS server นั้นเอง ในโลก internet DNS เป็นส่วนที่สำคัญมากๆ มันทำให้เราพิมพ์ google.co.th แล้วสามารถ connect ไปที่ google ได้เลยแทนที่จะต้องพิมพ์ 142.251.12.94 ซึ่งเป็น IP address ของ goole ที่ผม resolve ได้ในตอนที่เขียน blog นี้

โดย resource ตัวนี้จะทำงานใน private network ของเราบน Azure คอย resolve private domain name ของเราให้เป็น private IP address

แล้วก่อนหน้านี้ resolve domain name กันอย่างไรล่ะ

ใน Azure จริงๆ แล้ว มัมมี built-in DNS อยู่แล้ว เรียกว่า Azure-provided DNS มันจะเป็น configuration เนียนๆ อยู่ใน virtual network ของเรา ตรงนี้

โดย มันจะปรากฏในรูปแบบของ IP 168.63.129.16 ใน ใน VM ของเรา ที่ deploy ใน virtual network ที่ configure DNS server ไว้ตามข้างต้น โดย 168.63.129.16 สามารถ connect จาก Azure resources เท่านั้น

$ systemd-resolve --status | grep 'DNS Servers'
DNS Servers: 168.63.129.16

รายละเอียดเพิ่มเติม ของ 168.63.129.16 สามารถอ่านเพิ่มได้จาก What is IP address 168.63.129.16?

ทีนี้หากเราต้องการ เพิ่ม private domain name ก็แค่สร้าง private dns zone แล้ว link มันกับ virtual network ของเรา เท่านี้ Azure DNS ก็จะสามารถ resolve private domain name ของเราได้แล้ว

พอเราใช้ไปซักพักความต้องการเริ่มมากขึ้น เริ่มมี requirement ให้เราไปต่อกับ on-premise network ในส่วนของ connetivity นั้นก็ใช้ VPN หรือ Express Route ได้ตามปกติ แต่ในเรื่อง domain name resolution ล่ะ จะทำอย่างไรดี เพราะ on-prem ไม่สามารถ connect มาที่ 168.63.129.16 ที่อยู่บน Azure ของเราได้

ก่อนการมาของ Azure DNS Private Resolver เราใช้วิธีการสร้าง VM-Based DNS server ขึ้นมา พูดง่ายๆ สร้าง VM แล้วเอา DNS software เช่น Bind9 มา install เอง ถ้าอยากได้ SLA ที่เพิ่มขึ้นก็เอา VM มาใส่ VM Scale Set แล้ว ขั้นหน้าด้วย Load Balancer

นั่นหมายความว่าเราต้อง manage ทุกอย่างเอง ไม่ว่าจะเป็นการ hardening, OS update, Software upgrade, Backup และอื่นๆ อีกมากมาย

แล้วให้ on-premise DNS server ทำ Conditional Forward มาที่ VM-Based DNS server ของเรา

ในทางกลับกัน เราต้องต้อง configure Conditional Forward ลงไปที่ on-prem ด้วย เพื่อให้ server บน Azure สามารถ resolve domain name ของ on-premise ได้

Conditional Forward คือการ configure ใน DNS server ทำการ forward request ต่อยัง อีก DNS server หนึ่ง เช่น เรามี zone *.example.com อยู่ที่ server-A เราสามารถ configure ให้ DNS ของเราไปถามต่อที่ server-A ได้ หากมี client ถามว่า demo.example.com เป็น IP อะไร โดยที่ client ไม่ต้องรู้จัก server-A เลย

Azure DNS Private Resolver ทำงานอย่างไร

การที่จะทำ Hybrid DNS Solution บน Azure จะมี 2 resources ที่ทำงานร่วมกัน

DNS Private Resolver
DNS Forwarding Ruleset

DNS Private Resolver

ทำหน้าที่เป็น endpoint ในการทำ name resolution โดยประกอบด้วย 2 endpoints ที่ deploy อยู่คนละ dedicated subnet คือ

Inbound endpoints: เป็น ingress subnet โดย 1 endpoint จะมี 1 IP address ของ Load Balancer สำหรับ รับ domain name resolution request จาก on-premise หรือ resource ใน virtual network อื่น

Outbound endpoints: เป็น egress subnet ที่ใช้ออกไป query DNS servers อื่นๆ ใน subnet นี้จะไม่มี IP address ปรากฏ นั่นหมายความว่า outgoing IP address มีโอกาสเป็นไปได้ทั้ง subnet (ผมเดาว่าน่าจะใช้ technic เดียวกับ vnet integration ของ app service)

DNS Forwarding Ruleset

ทำหน้าที่เป็น conditional forward configuration ใน vnet ของเรา โดย Ruleset ก็ตามชื่อเลยครับ เป็นกลุ่มของ conditional forward rule โดย rule จะมีหน้าตาดังนี้

และการจะใช้งาน DNS Forwarding Ruleset ได้ ก็ต้องเอามันไป link กับ virtual network ตาม concept เดียวกับ Private DNS Zone

ยังจำได้ไหม ตัว resolver มี outbound endpoint ซึ่ง deploy ใน dedicated subnet ใน virtual network ดังนั้น ตัว outbound endpoint ก็จะทำตาม DNS Forwarding Ruleset ที่เรา link ไว้ด้วย

เอ๊ะ! ถ้าเรามีทั้ง Private DNS Zone Link และ DNS Forwarding Ruleset Link ด้วยมันจะทำงานอย่างไร ?

มันจะ resolve ตาม order นี้ครับ

Private DNS Zone
DNS Forwarding Ruleset
Azure-provided DNS Servers

สรุป ถ้า resolver ได้รับ name resolution request มาจาก client ผ่านทาง inbound endpoint IP address มันจะ forward ออกไปยัง outbound endpoint IP address ซึ่งจะทำการ resolve domain name ตามลำดับข้างต้น แล้ว response สิ่งที่ได้ไปให้กับ client

ถ้าพอนึกภาพออกแล้วเรามาลองลงมือทำกันดีกว่า

Architecure ที่เราจะลองทำหน้าตาประมาณนี้ครับ

เราจะมี 3 virtual network ดังนี้

On-Prem: เป็นตัวแทนของ on-premise
Hub: เป็นตัวแทนของ Hub network บน Azure ที่เป็นศูนย์รวมของ connectivity ต่างๆ
Spoke: เป็น virtual network ของ application ที่จะมา deploy ใน Azure

โดย

ที่ On-Prem จะมี DNS server ที่มี DNS records ของ domain *.onprem.contoso.com และทำ conditional forward domain *.private.contoso.com ไปที่ Resolver ที่ Hub
ที่ Hub จะมี DNS Private Resolver พระเอกของเรา, Private DNS Zone *.private.contoso.com และ DNS Forwarding Ruleset พระเอกของเราอีกคน เอาไว้ทำ conditional forward *.onprem.contoso.com ลงไปที่ On-Prem โดยใน virtual network นี้จะมี VM 1 server เอาไว้ทดสอบ name resolution
ที่ Spoke มี VM 1 server เอาไว้ทดสอบ name resolution เช่นกัน

เรามาเริ่มสร้างกันเลย

Create Resource Group

az group create \
--name rg-demodns-az-asse-sbx-001 \
--location southeastasia

Create Hub

Virtual Network

az network vnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vnet-demodnshub-az-asse-sbx-001 \
--address-prefixes 10.1.0.0/16

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--address-prefixes 10.1.1.0/24

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-inbound-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--address-prefixes 10.1.2.0/28

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-outbound-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--address-prefixes 10.1.2.16/28

Virtual Machine

SUBNET_ID=$(
az network vnet subnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az vm create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vm-hub-az-asse-sbx-001 \
--computer-name vm-hub-az-asse-sbx-001 \
--image UbuntuLTS \
--size Standard_D2s_v4 \
--accelerated-networking true \
--subnet ${SUBNET_ID} \
--nsg-rule SSH \
--admin-username azureuser \
--ssh-key-values /home/sawitmee/.ssh/id_rsa.pub

Private DNS Zone

az network private-dns zone create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name private.contoso.com

az network private-dns record-set a add-record \
--resource-group rg-demodns-az-asse-sbx-001 \
--zone-name private.contoso.com \
--record-set-name test \
--ipv4-address 10.10.10.10

az network private-dns link vnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name link-vnet-demodnshub-az-asse-sbx-001 \
--zone-name private.contoso.com \
--virtual-network vnet-demodnshub-az-asse-sbx-001 \
-e false

Private Resolver

VNET_ID=$(
az network vnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vnet-demodnshub-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az dns-resolver create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name adpr-hub-az-asse-sbx-001 \
--id ${VNET_ID}

SUBNET_ID=$(
az network vnet subnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--name snet-inbound-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az dns-resolver inbound-endpoint create \
--resource-group rg-demodns-az-asse-sbx-001 \
--dns-resolver-name adpr-hub-az-asse-sbx-001 \
--name snet-inbound-az-asse-sbx-001 \
--ip-configurations "[{private-ip-address:'',private-ip-allocation-method:'Dynamic',id:'$SUBNET_ID'}]"

SUBNET_ID=$(
az network vnet subnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--name snet-outbound-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az dns-resolver outbound-endpoint create \
--resource-group rg-demodns-az-asse-sbx-001 \
--dns-resolver-name adpr-hub-az-asse-sbx-001 \
--name snet-outbound-az-asse-sbx-001 \
--id "${SUBNET_ID}"

Create Spoke ( + Peering )

Virtual Network

az network vnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vnet-demodnsspoke-az-asse-sbx-001 \
--address-prefixes 10.2.0.0/16 \
--dns-servers 10.1.2.4

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--vnet-name vnet-demodnsspoke-az-asse-sbx-001 \
--address-prefixes 10.2.1.0/24

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-inbound-az-asse-sbx-001 \
--vnet-name vnet-demodnsspoke-az-asse-sbx-001 \
--address-prefixes 10.2.2.0/28

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-outbound-az-asse-sbx-001 \
--vnet-name vnet-demodnsspoke-az-asse-sbx-001 \
--address-prefixes 10.2.2.16/28

Peering

az network vnet peering create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vpeer-vnet-demodnsspoke-az-asse-sbx-001-vnet-demodnshub-az-asse-sbx-001 \
--vnet-name vnet-demodnsspoke-az-asse-sbx-001 \
--remote-vnet vnet-demodnshub-az-asse-sbx-001 \
--allow-vnet-access

az network vnet peering create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vpeer-vnet-demodnshub-az-asse-sbx-001-vnet-demodnsspoke-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--remote-vnet vnet-demodnsspoke-az-asse-sbx-001 \
--allow-vnet-access

Virtual Machine

SUBNET_ID=$(
az network vnet subnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--vnet-name vnet-demodnsspoke-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az vm create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vm-spoke-az-asse-sbx-001 \
--computer-name vm-spoke-az-asse-sbx-001 \
--image UbuntuLTS \
--size Standard_D2s_v4 \
--accelerated-networking true \
--subnet ${SUBNET_ID} \
--nsg-rule SSH \
--admin-username azureuser \
--ssh-key-values /home/sawitmee/.ssh/id_rsa.pub

Test

nslookup test.private.contoso.com

Create On-Premise ( +Peering )

Virtual Network

az network vnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vnet-demodnsonprem-az-asse-sbx-001 \
--address-prefixes 10.3.0.0/16

az network vnet subnet create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--vnet-name vnet-demodnsonprem-az-asse-sbx-001 \
--address-prefixes 10.3.1.0/24

Peering

az network vnet peering create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vpeer-vnet-demodnsonprem-az-asse-sbx-001-vnet-demodnshub-az-asse-sbx-001 \
--vnet-name vnet-demodnsonprem-az-asse-sbx-001 \
--remote-vnet vnet-demodnshub-az-asse-sbx-001 \
--allow-vnet-access

az network vnet peering create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vpeer-vnet-demodnshub-az-asse-sbx-001-vnet-demodnsonprem-az-asse-sbx-001 \
--vnet-name vnet-demodnshub-az-asse-sbx-001 \
--remote-vnet vnet-demodnsonprem-az-asse-sbx-001 \
--allow-vnet-access

DNS Server ( Windows )

SUBNET_ID=$(
az network vnet subnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--vnet-name vnet-demodnsonprem-az-asse-sbx-001 \
--name snet-default-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az vm create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vm-dns-az-asse-sbx-001 \
--computer-name vmdns101s01 \
--image Win2019Datacenter \
--size Standard_D4s_v3 \
--accelerated-networking true \
--subnet ${SUBNET_ID} \
--nsg-rule RDP \
--admin-username azureuser \
--admin-password "<YOUR-PASSWORD>"

Setup DNS server

ทำตามนี้นะครับ Install and Configure DNS Server on Windows Server 2019

Create Zone And Conditional Forward

Test

nslookup test.onprem.contoso.com 127.0.0.1
nslookup test.private.contoso.com 127.0.0.1

Create DNS Forwarding Ruleset

Create Rulesets


OUTBOUND_ID=$(
az dns-resolver outbound-endpoint show \
--resource-group rg-demodns-az-asse-sbx-001 \
--dns-resolver-name adpr-hub-az-asse-sbx-001 \
--name snet-outbound-az-asse-sbx-001 \
--query id \
--output tsv
)

az dns-resolver forwarding-ruleset create \
--resource-group rg-demodns-az-asse-sbx-001 \
--dns-forwarding-ruleset-name dfrs-onpremcontosocom-az-asse-sbx-001 \
--outbound-endpoints "[{id:'${OUTBOUND_ID}'}]"

VM_ID=$(
az vm show \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vm-dns-az-asse-sbx-001 \
--query id \
--output tsv
)

VM_IPADDR=$(
az vm list-ip-addresses \
--ids ${VM_ID} \
--query '[].virtualMachine.network.privateIpAddresses' \
--output tsv
)

az dns-resolver forwarding-rule create \
--resource-group rg-demodns-az-asse-sbx-001 \
--ruleset-name dfrs-onpremcontosocom-az-asse-sbx-001 \
--forwarding-rule-name onprem-contoso-com \
--domain-name onprem.contoso.com. \
--target-dns-servers "[{ip-address:'${VM_IPADDR}',port:53}]"

Link DNS forwarding ruleset to VNET

VNET_ID=$(
az network vnet show \
--resource-group rg-demodns-az-asse-sbx-001 \
--name vnet-demodnshub-az-asse-sbx-001 \
--query "id" \
--output tsv
)

az dns-resolver vnet-link create \
--resource-group rg-demodns-az-asse-sbx-001 \
--name link-vnet-demodnshub-az-asse-sbx-001 \
--ruleset-name dfrs-onpremcontosocom-az-asse-sbx-001 \
--id ${VNET_ID}

Test from VM in Hub

nslookup test.private.contoso.com
nslookup test.onprem.contoso.com

Test from VM in Spoke

nslookup test.private.contoso.com
nslookup test.onprem.contoso.com

เพิ่มเติม
ถ้าเรามี firewall ที่ Hub

แนะนำให้ enable DNS Proxy ที่ firewall แล้วชี้ DNS Server ของ firewall มาที่ Inbound Endpoint ของ DNS Private Zone Resolver

ส่วนที่ Spoke Virtual Network ให้ set DNS Server เป็น Private IP address ของ Firewall

References

CLI to get your current IP address

8P Inc. — Sun, 10 Oct 2021 03:44:02 +0000

curl ifconfig.co
curl ifconfig.co/json
curl ifconfig.me
curl ifconfig.io
curl wtfismyip.com/text
curl wtfismyip.com/json
curl icanhazip.com
curl icanhazip.com
curl ipinfo.io
curl ipinfo.io/ip
curl checkip.amazonaws.com
curl api.ipify.org
curl ipecho.net/plain
curl whatismyip.akamai.com
curl ident.me

dig +short myip.opendns.com @resolver1.opendns.com

REF: https://www.reddit.com/r/devops/comments/blh7kv/url_to_get_just_an_ip_with_no_garbage/

LFS258 [11/15]: Logging and Troubleshooting

8P Inc. — Sun, 19 Apr 2020 10:39:15 +0000

TL;DR

Basic Troubleshooting Steps: ต้องไล่จากจุดที่เห็นชัดที่สุด ที่เล็กที่สุด แล้วจึงค่อยๆ ขยาย scope ขึ้นไปเรื่อยๆ
Ephemeral Containers: เป็นวิธีที่จะช่วยให้เรา debug ปัญหาที่ยากต่อการ reproduce ได้สะดวกยิ่งขึ้น โดยการเพิ่ม container เข้าไปยัง Pod ที่ run อยู่ feature นี้ยังเป็น alpha อยู่ อาจเปลี่ยนแปลงได้ตลอดเวลา และ มัน disable โดย default ถ้าจะใช้ต้องไปเปิด feature gates ที่ api-server ก่อน
Cluster Start Sequence: เริ่มจาก systemd ไป start kubelet และ container engine จากนั้น kubelet start static pod ที่เป็น control plane จากนั้น kube-controller-manager ซึ่งเป็น 1 ใน static pods ทำการอ่านค่าจาก etcd แล้ว create resource ต่างๆ ที่เหลือทั้งหมด
Monitoring: ตอนนี้ใช้ Metric Server เป็นตัวรวบรวม metric ต่างๆ และ provide standard API ให้คนอื่นเรียกใช้ผ่านมัน
Plugins: ถ้า command ของ kubectl ไม่เพียงพอกับความต้องการของเรา เราสามารถเขียนเพิ่มเองได้ในรูปของ plugins
Managing Plugins: มี project ชื่อ krew เป็น plugin ของ kubelet ที่ทำหน้าที่เป็น plugin manager คอยจัดการ plugin ต่างๆ ให้ ทั้ง install, upgrade และ uninstall
Sniffling Traffic With Wireshark: ใช้ plugin หนึ่งของ krew ชื่อ sniff โดยมันจะไป start docker container ที่มี tcpdump มา dump network ของ container เรา
Logging Tools: kuebernetes ใช้ fluentd เป็น unified logging layer เพื่อรวบรวม log แล้ว ship ไป ยัง logging backend ต่างๆ
More Resources

Basic Troubleshooting Steps

ในการ troubleshoot ปัญหาที่เกิดขึ้นใน kubernetes cluster ของเราควรเริ่มต้นจากอะไรที่เห็นชัดเจนและเล็กที่สุดก่อน จากนั้นค่อยๆ ขยายขึ้นมาในระดับ cluster โดย steps ทำงานเป็นได้ดังนี้

Error ที่เกิดขึ้นจาก command line
Log และ สถานะของ Pods
ใช้ shell เพื่อเข้าไป troubleshoot ใน pods หรือ container
ตรวจสอบสถานะ และ resources ของ Node
RBAC, SELinux หรือ AppArmor สำหรับ security settings
ตรวจสอบ API calls ของ kube-apiserver
Enable auditing
ตรวจสอบ network ระหว่าง node รวมทั้ง DNS และ firewall
ตรวจสอบ master server controller ว่า run ครบหรื่อมี error อะไรเกิดขึ้นหรือไม่

Ephemeral Containers

ตั้งแต่ v1.16 เป็นต้นมา เราสามารถเพิ่ม container เข้าไปยัง Pod ที่ run อยู่ได้ โดยที่ไม่ต้อง re-create pod ใหม่ ด้วยความสามารถนี้ช่วยให้ investigate ปัญหาที่ยากต่อการ reproduce ได้สะดวกยิ่งขึ้น container ทีเพิ่มเข้าไปใน Pods ที่ run อยู่เรียกว่า "ephemeral containers"

feature นี้ยังคงเป็น alpha อยู่ อาจเปลี่ยนแปลงได้

ด้วยความที่มันถูกเพิ่มเข้าไปใน Pod run อยู่แล้ว ทำให้มันไม่มีความสามารถบางเหมือน container ทั่วไป เช่น

ไม่มี ports ดังนั้นจึงระบุ ports, livenessProbe และ readinessProbe ไม่ได้
เนื่องจาก Pod resource มีคุณสมบัติ immutable (เปลี่ยนแปลงไม่ได้) ดังนั้น ephemeral containers ใช้ resources ไม่ได้

สามารถดูคุณสมบัติเพิ่มเติมได้จาก EphemeralContainer reference documentation

การเพิ่ม ephemeral containers ไม่สามารถทำผ่าน pod.spec โดยใช้ kubectl edit ได้

ephemeral containers ถูก disable โดย default ดังนั้นต้องทำการ enable ก่อนโดยเพิ่ม --feature-gates=EphemeralContainers=true ใน options ของ api-server ใน /etc/kubernetes/manifests/ kube-apiserver.yaml

การใช้งาน Ephemeral Container ก่อน v1.18 ต้องสั่งงานผ่าน API ดังนี้

# สร้าง pod ตัวอย่างที่ไม่มี shell 

$ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
pod/ephemeral-demo created

# เพิ่ม ephemeral container เข้าไปใน pod

$ cat > ec.json << EOF
{
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
            "name": "ephemeral-demo"
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}
EOF

$ kubectl replace --raw /api/v1/namespaces/default/pods/ephemeral-demo/ephemeralcontainers -f ec.json
$ kubectl describe pod ephemeral-demo
(...)
Ephemeral Containers:
debugger:
    Image:      busybox
    Port:       <none>
    Host Port:  <none>
    Command:
    sh
    Environment:  <none>
    Mounts:       <none>
(...)

# Attach ไปยัง ephemeral container เพื่อทำการ debug

$ kubectl attach -it example-pod -c debugger

ถ้าใน v1.18 สามารถ run kubectl alpha debug -it ... ได้เลย

# สร้าง pod ตัวอย่างที่ไม่มี shell 

$ kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
pod/ephemeral-demo created

# เพิ่ม ephemeral container เข้าไปใน pod เพื่อทำการ debug

$ kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

Cluster Start Sequence

ถ้าเรา setup cluster ของเราด้วย kubeadm หรือ tool automation อื่นๆ ที่ใช้ kubeadm ลำดับการ startup ของ cluster เราจะเริ่มต้นดังนี้

systemd ของแต่ละเครื่องใน cluster จะทำการ start kubelet ขึ้นมาก่อน ซึ่งเราสามารถตรวจสอบ parameter ต่างๆ ในการ start kubelet ได้จาก configuration file ของมันที่ {/etc,/usr/lib/systemd}/system/kubelet.service.d/10-kubeadm.conf
kubelet จะทำการ start Static Pod โดยเข้าไปอ่าน file ที่ระบุมาใน parameter --config= ซึ่ง default จะเป็น /var/lib/kubelet/config.yaml จากนั้น หาตัวแปร staticPodPath ซึ่งเป็นตัวที่ระบุ path ที่เก็บ configuration file ของแต่ละ static pod ซึ่ง โดย default จะชี้ไปที่ /etc/kubernetes/manifests/ จากนั้นจึงทำการ start static pod ตาม configuration file โดยปกติจะมี 4 control plane pods นี้
- etcd
- kube-controller-manager
- kube-scheduler
- kube-apiserver
kube-controller-manager ที่ทำหน้าที่เป็น watch loop และ controllers จะอ่าน data จาก etcd เพื่อทำการสร้าง resources ที่เหลือทั้งหมด

Monitoring

การ monitoring ทุกคนคงรู้จักกันดีอยู่แล้วว่ามันคือการไปเอาค่า (metric) ต่างๆ จาก infrastructure และ application เพื่อนำมาตรวจวัดและวิเตราะห์ เพื่อต่อยอดในการทำงานอื่นๆ ต่อไป

ใน kubernetes เมื่อก่อนจะใช้ Heapster ในการรวบรวม metrics ตาม components ต่างๆ ใน cluster แต่ตอนนี้ Heapster ได้ deplicated ไปแล้ว และมีสิ่งที่มาแทนเรียกว่า Metrics Server โดย Metric Server ทำหน้าที่ตัวรวบรวม metrics เช่นเดิม เพิ่มเติมคือมี standard API ซึ่งจะให้ agent ต่างๆ เข้ามาดึงข้อมูลไปทำงานต่อ เช่น การทำ autocalers (เพิ่มจำนวน replica ตาม workload) เป็นต้น

ในส่วนของ data store และ visualization ของที่คู่กับ Heapster ก็คือ cAdvisor เมื่อ Heapster ไม่อยู่แล้วจึงมี tool ตัวอื่นขึ้นมมาแทนนั่นคือ Prometheus ซึ่งเป็น application ที่อยู่ใน CNCF เช่นเดียวกับ Kubernetes โดย Prometheus ทำหน้าที่เป็น plugin ของ kubernetes ที่ใช้ในการดึงค่าของ resources ต่างๆ ใน cluster ผ่าน Metric Server นอกจากนั้นมันยังมี library ในภาษาต่างๆ เพื่อ integrate และ ดึง metric ในระดับ application ด้วย

Plugins

ถ้า kubectl ไม่พอความต้องการของเรา เราสามารถเขียน sub-command เพิ่มได้เอง เพียงแค่ตั้งชื่อให้ขึ้นต้นว่า kubectl- เช่น kubectl-sniff แล้ววางไว้ใน directory ไหนก็ได้ที่ระบุไว้ใน environment variable ชื่อ PATH จากนั้นเปลี่ยน mode ให้ execute ได้ เราก้ได้ sub-comand ใหม่ขึ้นมาแล้ว

ตัวอย่างการสร้าง plugin ขึ้นมาใช้เอง

# สร้าง plugin และ register ให้ kubectl เรียกได้

$ cat > kubectl-foo << EOF
#!/bin/bash

# optional argument handling
if [[ "\$1" == "version" ]]
then
    echo "1.0.0"
    exit 0
fi

# optional argument handling
if [[ "\$1" == "config" ]]
then
    echo "\$KUBECONFIG"
    exit 0
fi

echo "I am a plugin named kubectl-foo"
EOF
$ chmod +x ./kubectl-foo
$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/admin/.local/bin:/home/admin/bin
$ sudo mv ./kubectl-foo /usr/local/bin

# List plugins

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-foo

# ทดลองใช้งาน

$ kubectl foo
I am a plugin named kubectl-foo
$ kubectl foo version
1.0.0

# จะเห็นว่า kubectl pass environment variables ทุกอย่างมาให้ script เราด้วย

$ export KUBECONFIG=~/.kube/config
$ kubectl foo config
/home/admin/.kube/config
$ KUBECONFIG=/etc/kube/config kubectl foo config
/etc/kube/config

ข้อควรรู้

ถ้าเราตั้งชื่อ plugin เป็น kubectl-foo-bar-baz เราจะใช้ได้แบบ kubectl foo bar baz

$ echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
$ sudo chmod +x ./kubectl-foo-bar-baz
$ sudo mv ./kubectl-foo-bar-baz /usr/local/bin

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-foo-bar-baz

$ kubectl foo bar baz arg1 --meaningless-flag=true
My first command-line argument was arg1

ในการเรียกใช้ plugin จะใช้ concept best match

$ echo -e '#!/bin/bash\n\necho "My fizz buzz command-line argument was $1"' > kubectl-fizz-buzz
$ echo -e '#!/bin/bash\n\necho "My fizz command-line argument was $1"' > kubectl-fizz
$ sudo chmod +x ./kubectl-fizz-buzz
$ sudo chmod +x ./kubectl-fizz
$ sudo mv ./kubectl-fizz-buzz /usr/local/bin
$ sudo mv ./kubectl-fizz /usr/local/bin

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-fizz
/usr/local/bin/kubectl-fizz-buzz

$ kubectl fizz buzz arg1
My fizz buzz command-line argument was arg1
$ kubectl fizz arg1
My fizz command-line argument was arg1

ถ้าตั้งชื่อมี underscore (_) เวลาเรียกใช้สามารถใช้ได้ทั้ง underscore (_) และ dash(-)

$ echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
$ sudo chmod +x ./kubectl-foo_bar
$ sudo mv ./kubectl-foo_bar /usr/local/bin

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-foo_bar

$ kubectl foo_bar
I am a plugin with a dash in my name
$ kubectl foo-bar
I am a plugin with a dash in my name

ถ้ามี file ชื่อซ้ำกันในแต่ละ directory ของ PATH file ที่อยู่ใน directory แรกจะถูกเรียกใช้งาน (overshadow)

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

$ echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' | sudo tee /usr/local/bin/kubectl-overshadow
$ echo -e '#!/bin/bash\n\necho "My second command-line argument was $1"' | sudo tee  /usr/sbin/kubectl-overshadow
$ sudo chmod +x /usr/local/bin/kubectl-overshadow
$ sudo chmod +x /usr/sbin/kubectl-overshadow

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-overshadow
/usr/sbin/kubectl-overshadow
- warning: /usr/sbin/kubectl-overshadow is overshadowed by a similarly named plugin: /usr/local/bin/kubectl-overshadow

error: one plugin warning was found

$ kubectl overshadow 1234
My first command-line argument was 1234

ไม่สามารถ override built-in sub-command ของ kubelet ได้

$ echo -e '#!/bin/bash\n\necho "My version is 1.0.0"' | sudo tee /usr/local/bin/kubectl-version
$ sudo chmod +x /usr/local/bin/kubectl-version

$ kubectl plugin list
The following compatible plugins are available:

/usr/local/bin/kubectl-version
- warning: kubectl-version overwrites existing command: "kubectl version"

error: one plugin warning was found

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:48:36Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

Managing Plugins

ถ้าหากคุณ develop plugin ออกมาได้ดี และ อยากจะ distribute ให้คนอื่นใช้ด้วย มี project ที่ชื่อว่า krew ซึ่งทำหน้าที่เป็น plugin manager ของ kubectl อ่านเพิ่มเติมการ upload plugin ของตัวเองได้จาก Developer Guide

ในส่วนนี้จะขอแสดงเพียงติดตั้งและใช้งานบน CentOS

Install and setup krew

# Installation
$ sudo yum install git
$ (
set -x; cd "$(mktemp -d)" &&
curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.{tar.gz,yaml}" &&
tar zxvf krew.tar.gz &&
KREW=./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" &&
"$KREW" install --manifest=krew.yaml --archive=krew.tar.gz &&
"$KREW" update
)
$ cat >> ~/.bashrc << EOF
export PATH="\${KREW_ROOT:-\$HOME/.krew}/bin:\$PATH"
EOF
$ source ~/.bashrc

# Verification
$ kubectl krew version
OPTION            VALUE
GitTag            v0.3.4
GitCommit         324f5ed
IndexURI          https://github.com/kubernetes-sigs/krew-index.git
BasePath          /home/admin/.krew
IndexPath         /home/admin/.krew/index
InstallPath       /home/admin/.krew/store
BinPath           /home/admin/.krew/bin
DetectedPlatform  linux/amd64

วิธีการใช้งาน

# Download the plugin list
$ kubectl krew update
Updated the local copy of plugin index.

# Discover plugins available on Krew
$ kubectl krew search
NAME                            DESCRIPTION                                         INSTALLED
access-matrix                   Show an RBAC access matrix for server resources     no
advise-psp                      Suggests PodSecurityPolicies for cluster.           no
apparmor-manager                Manage AppArmor profiles for cluster.               no
auth-proxy                      Authentication proxy to a pod or service            no
bulk-action                     Do bulk actions on Kubernetes resources.            no
(...)

# Choose a plugin from the list and install it
$ kubectl krew install whoami
Updated the local copy of plugin index.
Installing plugin: whoami
Installed plugin: whoami
(...)

# Use the installed plugin
$ kubectl whoami
kubecfg:certauth:admin

# List existing plugins
$ kubectl plugin list
The following compatible plugins are available:

/home/admin/.krew/bin/kubectl-krew
/home/admin/.krew/bin/kubectl-whoami

# Keep your plugins up-to-date
$ kubectl krew upgrade
Updated the local copy of plugin index.
Upgrading plugin: krew
Skipping plugin krew, it is already on the newest version
Upgrading plugin: whoami
Skipping plugin whoami, it is already on the newest version

# Uninstall a plugin you no longer use
$ kubectl krew uninstall whoami
Uninstalled plugin whoami

Sniffling Traffic With Wireshark

จากหัวข้อที่แล้วเรารู้จัก knew กันไปแล้ว คราวนี้เรามาใช้ plugin ของมันที่ชื่อว่า sniff เพื่อทำการ tcpdump network ภายใน container ของเรากัน โดยสามารถอ่านรายละเอียดได้จาก github ของ eldadru

$ sudo yum install wireshark
$ kubectl krew install sniff
Updated the local copy of plugin index.
Installing plugin: sniff
Installed plugin: sniff
(...)

$ kubectl run demo --image=nginx  --restart=Never
pod/demo created

$ kubectl sniff -p demo -c demo -o - | tshark -r -
INFO[0000] sniffing method: privileged pod              
INFO[0000] using tcpdump path at: '/home/admin/.krew/store/sniff/v1.4.1/static-tcpdump' 
INFO[0000] sniffing on pod: 'demo' [namespace: 'default', container: 'demo', filter: '', interface: 'any'] 
INFO[0000] creating privileged pod on node: 'kube-0002.novalocal' 
INFO[0000] pod created: &Pod{ObjectMeta:{ksniff-k9vxv ksniff- default
(...)
 45         37 192.168.93.128 -> 192.168.52.75 TCP 76 40910 > http [SYN] Seq=0 Win=28000 Len=0 MSS=1400 SACK_PERM=1 TSval=3831288949 TSecr=0 WS=128
 46         37 192.168.52.75 -> 192.168.93.128 TCP 76 http > 40910 [SYN, ACK] Seq=0 Ack=1 Win=27760 Len=0 MSS=1400 SACK_PERM=1 TSval=3831285944 TSecr=3831288949 WS=128
 47         37 192.168.93.128 -> 192.168.52.75 TCP 68 40910 > http [ACK] Seq=1 Ack=1 Win=28032 Len=0 TSval=3831288949 TSecr=3831285944
 48         37 192.168.93.128 -> 192.168.52.75 HTTP 145 GET / HTTP/1.1 
 49         37 192.168.52.75 -> 192.168.93.128 TCP 68 http > 40910 [ACK] Seq=1 Ack=78 Win=27776 Len=0 TSval=3831285945 TSecr=3831288950
 50         37 192.168.52.75 -> 192.168.93.128 TCP 307 [TCP segment of a reassembled PDU]
 51         37 192.168.52.75 -> 192.168.93.128 HTTP 680 HTTP/1.1 200 OK  (text/html)
(...)

จะเห็นว่า หลักการของมันคือการ ไปสร้าง docker container corfr/tcpdump ที่ attach เข้า network เดียวกับ pod เรา แล้วทำการ tcpdump

Logging Tools

เรื่อง Log ถือเป็นเรื่องใหญ่มากในวงการ IT หลักการโดยทั่วไปของคือ ทำการ ingest log เข้ามาเก็บไว้ที่ seach engine แล้วทำการ query ด้วย search syntax เพื่อแสดงผลผ่าน dashboard ซึ่ง application ที่ได้รับความนิยมคงหนีไม่พ้น Elastic Stack ซึ่งประกอบไปด้วย Elasticsearch, Logstash และ Kibana

ใน kubernetes, kubelet จะทำการ write container log ลง local file ผ่าน Docker logging driver จึงมักใช้ Fluentd หรือ Fluent Bit ในการ รวม log แล้วจึงส่งออกไปยัง log server ไม่ว่าจะเป็น Elasticsearch หรือ Prometheus

Logging Architecture ของ kubernetes มีดังนี้

Logging at the node level

ไม่มีการ ship ออกไปยัง logging backend ทุกอย่างอยู่บนเครื่องใช้ log rotate engine ของ OS นั้นๆ ในการ rotate log ถ้าใน linux ก็จะเป็น logrotate
Cluster-level logging architectures

2.1 Using a node logging agent

container ทำการเขียน log ออกทาง stdout และ stderr จากนั้น log driver ของ container runtime จะทำการ write log ลง local file จากนั้น เราจึงใช้ logging agent เช่น fluentd ในการ ship log ออกไปยัง logging backend อย่างเช่น Elasticsearch หรือ Stackdriver Logging

2.2 Using a sidecar container with the logging agent

Streaming sidecar container

ในกรณีที่ application container ไม่สามารถ write log ไปยัง stdout และ stderr ได้ จึงต้องมี sidecar ซึ่งเป็น container ที่อยู่ใน Pod เดียวกับ application container เพื่อทำการอ่าน file, socket หรือ journald เพื่อ redirect มายัง stdout และ stderr เพื่อให้ log driver ของ container runtime จะทำการ write log ลง local file และ logging agent ทำการอ่าน file นั้นแล้ว ship ไปยัง logging backend ต่อไป

Sidecar container with a logging agent

ถ้าคุณไม่สะดวกใช้ node-level logging agent ในการ ship log คุณสามารถ install sidecar ที่ทำหน้าที่เป็น logging agent คู่กับ application container เพื่อ ship log ตรงไปยัง logging backend เลยก็ได้

Exposing logs directly from the application

วิธีสุดท้ายถ้าคุณสามารถปรับ application ให้ ship log ไปยัง logging agent เองได้เลย วิธีนี้ก็สามารถทำได้เช่นกัน

More Resources

LFS258 [10/15]: Scheduling

8P Inc. — Tue, 14 Apr 2020 01:51:53 +0000

TL;DR

Kube-Scheduler: เป็น process หลักในการทำเรื่อง schedule โดยมีหลักการทำงาน 2 ขั้นตอนคือ Filtering คือ filter nodes ที่ไม่เหมาะสมออกไป และ Scoring เป็นการให้คะแนน node ที่ผ่านการ filering เพื่อหา node ที่้เหมาะสมกับ pod มากที่สุด
Predicates and Priorities: เป็น schedule policy ตัว stable ของ kubenetes
Extension Points and Plugins: เป็น schedule policy ตัวใหม่ของ kubernetes ที่เพิ่งเป็น beta ใน v1.18
Pod Specification: เราสามารถกำหนดความสามารถพิเศษและความต้องการของ Pod ใน pod specification เพื่อชี้นำการ schedule pod ไปยัง node ที่เหมาะสมของ kubernetes ได้
Specifiying the nodeName: เป็นการระบุ hostname ของ node ที่เราต้องการให้ Pod ไปอยู้
Specifiying the nodeSelector: เป็นการระบุ labels ของ node ที่ pod ต้องการ ให้ scheduler ส่ง pod ไป run
Pod Affinity Rules: เป็นการระบุให้ pod ชุดหนึ่งอยู่ใน location เดียวกับ
Node Affinity Rules: เหมือน nodeSelector แต่เพิ่มความยืดหยุ่นของ affinity เข้ามา
Taints: เป็นการระบุข้อจำกัดของ node เช่น เฉพาะกลุ่ม หรือ มี hardware พิเศษติดตั้งอยู่
Tolerations: เป็นการระบุความทนทานต่อ taints ของ pods โดย ถ้า pod มี toleration ต่อ taints ของ node จะสามารถถูก schedule ไป run ใน node นั้นได้
Custom Scheduler: ถ้า scheduler ที่เป็น default ไม่ถูกใจ เราสามารถ run ตัว scheduler นี้ขึ้นมาอีกตัว โดยที่ configuration ตามความต้องการของเรา เพื่อเป็น secondary scheduler ได้ หรือเขียนใหม่เองหมดก็ยังได้ แต่ ใน pod specification ต้องระบุ scheduler name ที่เราต้องการใช้ด้วย ไม่งั้นจะใช้ default scheduler

Kube-Scheduler

Kube-Scheduler ทำหน้าที่ในการหา worker node ที่เหมาะสมให้ pod ไป run โดยใช้ algorithm ที่ชื่อว่า "topology awareness" ผู้ใช้สามารถตั้ง priority ของ pod ได้ โดย pod ไหนมี priority มากกว่าจะสามารถแซงคิว pod ที่มี priority น้อยกว่า ในการ scheduling ได้

ในการ schedule pod ไป run นั้น Kube-Scheduler จะทำ 2 steps คือ

Filtering: ทำการ filter ให้เหลือแค่ node คุณสมบัติที่เหมาะสมกับ pod
Scoring: ทำให้คิดคะแนน (ranking) ด้วย algorithm ต่างๆ เพือหา node ที่เหมาะสมที่สุดที่จะนำ pod ไป run

ซึ่ง Schedule Policies ที่เลือกใช้ได้มี 2 แบบ

Predicates และ Priorities: predicates เป็นการ filtering โดยพิจารณาสถานะและพฤติกรรม ส่วน priority เป็นการใช้ function มาคำนวณคะแนน เพื่อหา node ที่เหมาะสมที่สุด
Extension points และ Plugins: เป็นการใช้ profile ที่เกิดจากการนำ state หรือเป็นมาการเรียนว่า "Extension points" มารวมกัน เช่น QueueSort, Filter, Score, Bind, Reserve, Permit, เป็นต้นมารวมกัน เพื่อหา node ที่เหมาะสมที่สุด

เราสามารถชี้นำการตัดสินใจของ Kube-Scheduler ได้ด้วยการระบุคุณสมบัติพิเศษ (Labels) หรือข้ออจำกัด (taints) ให้กับ nodes หรือ pods ที่มีอยู่ก่อน และ ระบุความสามารถที่สอดคล้องกันให้กับ pods ที่เราจะ schedule โดยตัวอย่างการชี้น ของ default scheduler มีดังนี้

affinity: ระบุว่า pods นี้ต้อง run ใน node ที pods ที่มี labels นี้ run อยู่ก่อนแล้ว
antiaffinity: ระบุว่า pods นี้ run ใน node ทีไม่มี pods ที่มี labels นี้ run อยู่
taint: เป็นข้อจำกัดของ nodes ที่เราระบุเข้าไป
toleration: เป็น property ของ pod ที่ทนต่อ taints ที่ node มีได้ (ทนได้ ก็คือ schedule pods ไป run ได้)

นอกจากนี้เรายังสามารถเขียน program ของเราเองเพื่อมา run เป็น custom scheduler ใน kubernetes cluster ก็

รายละเอียดเพิ่มเติมดูได้ในหัวข้อด้านล่างเลย 😁

Predicates and Priorities

Predicates (Deplicated in v1.18)

เป็นชุดของ Filter ที่ใช้ในการตรวจสอบความพร้อมของ nodes โดยถ้า nodes ไหนมีคุณสมบัติไม่ผ่านก็จะถูก filter ทิ้งไป โดย list ของ predicates มีดังนี้
- CheckNodeConditionPred
- CheckNodeUnschedulablePred
- GeneralPred
- HostNamePred
- PodFitsHostPortsPred
- MatchNodeSelectorPred
- PodFitsResourcesPred
- NoDiskConflictPred
- PodToleratesNodeTaintsPred
- PodToleratesNodeNoExecuteTaintsPred
- CheckNodeLabelPresencePred
- CheckServiceAffinityPred
- MaxEBSVolumeCountPred
- MaxGCEPDVolumeCountPred
- MaxCSIVolumeCountPred
- MaxAzureDiskVolumeCountPred
- MaxCinderVolumeCountPred
- CheckVolumeBindingPred
- NoVolumeZoneConflictPred
- CheckNodeMemoryPressurePred
- CheckNodePIDPressurePred
- CheckNodeDiskPressurePred
- EvenPodsSpreadPred
- MatchInterPodAffinityPred
เพิ่มเติม
Priorities (Deplicated in v1.18)

เป็นการจัดลำดับความสำคัญของ resources ถ้า Pod และ Node Affinity ไม่ได้ configure ไว้ว่าเป็น SelectorSpreadPriority (จัดลำดับตามจำนวน pods ที่ run อยู่ใน node) Kube-Scheduler จะเลือก node ที่มีจำนวน pod ถูก schedule ไปน้อยที่สุด list ของ priorities มีดังนี้
- EqualPriority
- MostRequestedPriority
- RequestedToCapacityRatioPriority
- SelectorSpreadPriority
- ServiceSpreadingPriority
- InterPodAffinityPriority
- LeastRequestedPriority
- BalancedResourceAllocation
- NodePreferAvoidPodsPriority
- NodeAffinityPriority
- TaintTolerationPriority
- ImageLocalityPriority
- ResourceLimitsPriority
- EvenPodsSpreadPriority
เพิ่มเติม

Scheduling Policies

เราสามารถ custom Predicates และ Priorities เพื่อสร้างเป็น custom scheduler ได้ โดยสร้าง file ดังนี้

{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
    {"name" : "PodFitsHostPorts"},
    {"name" : "PodFitsResources"},
    {"name" : "NoDiskConflict"},
    {"name" : "NoVolumeZoneConflict"},
    {"name" : "MatchNodeSelector"},
    {"name" : "HostName"}
    ],
"priorities" : [
    {"name" : "LeastRequestedPriority", "weight" : 1},
    {"name" : "BalancedResourceAllocation", "weight" : 1},
    {"name" : "ServiceSpreadingPriority", "weight" : 1},
    {"name" : "EqualPriority", "weight" : 1}
    ],
"hardPodAffinitySymmetricWeight" : 10,
"alwaysCheckAllPredicates" : false
}

และ run scheduler ขึ้นมาอีกตัวโดยแก้ option --policy-config-file=<file>, --use-legacy-policy-config=true และ --scheduler-name=<name> จากนั้น run pod โดย ระบุ scheduler name ดังนี้

apiVersion: v1
kind: Pod
metadata:
name: annotation-second-scheduler
labels:
    name: multischeduler-example
spec:
schedulerName: <name>
containers:
- name: pod-with-second-annotation-container
    image: k8s.gcr.io/pause:2.0

Extension Points and Plugins

เป็น feature ใหม่ใน v1.18 เลย แต่ยังเป็น beta อยู่

เป็น scheduling profile ที่เกิดจากการรวม Extension points เข้าด้วยกัน เราสามารถระบุ profile ด้วยการ เพิ่ม option ให้ kube-scheduler ดังนี้ kube-scheduler --config <filename>

สามารถระบุหลาย profile และให้ pods เรียกใช้โดยการบ้างอิง scheduler name ใน pod specification

Extension points
- QueueSort: เป็นการ sort pods ที่อยู่ใน scheduling queue
- PreFilter: เป็นการ pre-process หรือ check Pod และ cluster ก่อนทำการ Filter
- Filtering: เหมือน predicates เป็นการ filter เอา nodes ที่มีคุณสมบัติไม่ผ่านออกไป
- PreScore: เป็นการทำ pre-scoring
- Score: ให้คะแนนแต่ละ node และ เลือก node ที่มีคะแนนมากที่สุด
- Reserve: เป็น stage ที่ notify plugin ว่า resource กำลังถูก reserve ให้กับ pod
- Permit: สามารถ ป้องกัน (prevent) หรือ น่วงเวลา (delay) การ bind pod ไปยัง node
- PreBind: ทำงานต่างๆ ก่อนที่จะ bind pod
- Bind: ทำการ bind pod ไปยัง node ที่ reserve resource ไว้
- PostBind: เป็น stage หลังจาก bind pod ไปยัง node เรียบร้อย
- UnReserve: เป็น stage ที่ Pod ถูก reject หลังจากทำการ reserve resource ไม่สำเร็จ โดย pod จะกลับไปอยู่ stage Permit อีกครั้ง
Scheduling plugins
- Enable โดย default
  - DefaultTopologySpread (PreScore, Score): กระจาย pods ไปยัง node ตาม Services, ReplicaSets และ StatefulSets ของมัน
  - ImageLocality (Score): กระจาย posd ไม่ยัง node ที่มี image ของ pod นั้นอยู่แล้ว
  - TaintToleration (Filter, Prescore, Score): กระจายตามหลัก Taint and Toleration
  - NodeName (Filter): แจก Pod ไปยัง Node ทีมี name node ตรงกับที่ระบุไว้ใน pod specification
  - NodePorts (PreFilter, Filter): แจก Pod ไปยัง Node ที่มี port ที่ต้องการใช้ว่างอยู้
  - NodePreferAvoidPods (Score): ให้คะแนน node ตาม annotation scheduler.alpha.kubernetes.io/preferAvoidPods
  - NodeAffinity (Filter, Score): แจก pod ตาม nodeSelector and nodeAffinity
  - PodTopologySpread (Filter, PreScore, Score): แจก pod ตาม Pod topology
  - NodeUnschedulable (Filter): Filter node ที่มี .spec.unschedulable=true ออกไป
  - NodeResourcesFit (PreFilter, Filter): Filter node ที่มี resource ไม่พอตามที่ pod request ออกไป
  - NodeResourcesBallancedAllocation (Score): เลือก node ที่ถ้า schedule pod ไป จะทำให้ resource ในแต่ละ node ใน cluster balance ขึ้น
  - NodeResourcesLeastAllocated (Score): เลือก node ที่มี resource เหลือเยอะที่สุด
  - VolumeBinding (Filter): เลือก node ที่มี volume ที่ pod ต้องการ bind อยู่
  - VolumeRestrictions (Filter): เลือก node ที่มี volume ที่ pod ต้องการ bind อยู่ และ pod มีสิทธิ์ใช้
  - VolumeZone (Filter): เลือก node ที่มี volume ที่อยู่ใน zone ที่ pod ต้องการ
  - NodeVolumeLimits (Filter): เลือก node ที่ satisfy CSI volume limits
  - EBSLimits (Filter): เลือก node ที่ satisfy AWS EBS volume limits
  - GCEPDLimits (Filter): เลือก node ที่ satisfy GCP-PD volume limits
  - AzureDiskLimits (Filter): เลือก node ที่ satisfy Azure disk volume limits
  - InterPodAffinity (PreFilter, Filter, PreScore, Score): แจก pod ตาม inter-Pod affinity and anti-affinity
  - PrioritySort (QueueSort): เลือก node ตาม priority based sorting แบบ default
  - DefaultBinder (Bind): เลือก node ตาม binding mechanism แบบ default
- ต้อง manual enable เองผ่าน API
  - NodeResourcesMostAllocated (Score): เลือก node ที่มี resource เหลือน้อยที่สุด
  - RequestedToCapacityRatio (Score): เลือก node ตาม function ของ resource ที่ allocate
  - NodeResourceLimits (PreScore, Score): เลือก node ที่ มี resource พอ ตามที่ Pod request
  - CinderVolume (Filter): เลือก node ที่ satisfy OpenStack Cinder volume limits
  - NodeLabel (Filter, Score): filter และ ให้คะแนน node ตาม labels ที่ configure ไว้
  - ServiceAffinity (PreFilter, Filter, Score): กระจาย Pods ที่อยู่ใน service เดียวกันไปยัง แต่ละ node ไม่ซ้ำกัน

Pod Specification

ในการ schedule pod ไป run ใน node ที่เหมาะสมนอกจากความพร้อมของ node แล้ว อีกปัจจัยที่สำคัญคือ Pod Specification โดย parameter ที่มีผลต่อการ schedule เช่น

nodeName: ใช้ระบุชื่อ node ที่ต้องการให้ scheduler นำ Pod ไป run
nodeSelector: ใช้ระบุ label ของ nodes ที่เหมาะสมกับ pod ตัวนั้นๆ
affinity: มีทั้ง affinity ซึ่งบอกว่า pod นี้ต้องอยู่ร่วมกับ pod ใด และ anti-affinity คือไม่อยู่ร่วมกับ pod ใด
schedulerName: ระบุชื่อของ scheduler ที่ใช้ในการ schedule pod ถ้าไม่ระบุใช้ default scheduler
tolerations: บอกว่า Pod นี้ทนต่อข้อจำกัด (taints) อะไรของ node ได้บ้าง

Specifiying the nodeName

เป็นการระบุที่ง่ายที่สุด ที่ไม่แนะนำ ซึ่งมาด้วยข้อจำกัดหลายอย่าง เช่น

ถ้า node name ที่เราระบุไปไม่มีอยู่จริง pod ก็จะไม่ถูก run
ถ้า node name ที่เราระบุไว้มี resource ไม่เพียงพอ pod ก็จะไม่ถูก run เช่นกัน
ใน cloud environment เราไม่สามารถคาดเดา node name ได้ ทำให้เราต้องแก้ไข configure ของเราทุกครั้งที่ย้าย cluster หรือ node ที่เราระบุตายไป

ตัวอย่างของ pod specification ที่ใช้ nodeName

$ kubectl get nodes
NAME                  STATUS   ROLES    AGE   VERSION
kube-0001.novalocal   Ready    master   88d   v1.17.1
kube-0002.novalocal   Ready    <none>   88d   v1.17.1
kube-0003.novalocal   Ready    <none>   88d   v1.17.1
$ cat > nodename.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-0003.novalocal
EOF
$ kubectl get pods -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          3m    192.168.32.60   kube-0003.novalocal   <none>           <none>

Specifiying the nodeSelector

เป็นการระบุที่ง่ายที่สุด ที่แนะนำ เนื่องจากเราสามารถสร้าง labels เดียวกันที่หลาย node ทำให้ถ้า node กใด node หนึ่งตายไป หรือไม่พร้อมด้วยสาเหตุใดก็ตาม ก็ยังมี node อื่นให้ schedule ไป

โดยเราต้องทำการ label node ก่อน ดังนี้

$ kubectl label nodes kube-0003.novalocal disktype=ssd

จากนั้น create pod ด้วย specification ดังนี้

$ kubectl get nodes --show-labels
NAME                  STATUS   ROLES    AGE   VERSION   LABELS
kube-0001.novalocal   Ready    master   88d   v1.17.1   (...),node-role.kubernetes.io/master=
kube-0002.novalocal   Ready    <none>   88d   v1.17.1   (...)
kube-0003.novalocal   Ready    <none>   88d   v1.17.1   (...)
$ kubectl label nodes kube-0003.novalocal disktype=ssd
node/kube-0003.novalocal labeled
$ kubectl get nodes --show-labels
NAME                  STATUS   ROLES    AGE   VERSION   LABELS
kube-0001.novalocal   Ready    master   88d   v1.17.1   (...),node-role.kubernetes.io/master=
kube-0002.novalocal   Ready    <none>   88d   v1.17.1   (...)
kube-0003.novalocal   Ready    <none>   88d   v1.17.1   (...),disktype=ssd,(...)
$ cat > nodeselector.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd
EOF
$ kubectl create -f nodeselector
pod/nginx created
$ kubectl get pods -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          19s   192.168.32.61   kube-0003.novalocal   <none>           <none>

โดย pod จะถูก schedule ไปยัง node ที่มี ทุก label ที่เรากำหนดไว้ใน pod specification ถ้าหาไม่มี node ไหน ตรงกับ specification pod นั้นจะมีสถานะเป็น Pending

เราสามารถใช้ nodeAffinity แทน nodeSelector ก็ได้

Node ใน Kubernetes cluster โดยปกติจะมี Built-in Labels ที่เรานำมาใช้ได้ โดยที่เราไม่ต้องกำหนดเอง ได้แก่

kubernetes.io/hostname
failure-domain.beta.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region
topology.kubernetes.io/zone
topology.kubernetes.io/region
beta.kubernetes.io/instance-type
node.kubernetes.io/instance-type
kubernetes.io/os
kubernetes.io/arch

Pod Affinity Rules

Pod Affinity เป็นการ schedule pod ตาม pod ที่มีอยู่ก่อนหน้า เนื่องจาก scheduler ต้องเข้าไปตรวจสอบทุก nodes ดังนั้น ใน cluster ใหญ่ๆ ที่มี node หลักร้อย nodes การใช้วิธีนี้จะมีผลต่อ performance ของ cluster

โดย Affinity Rules มี 2 แบบคือ

Affinity คือ pods เหล่านี้ต้องอยู่ใน location เดียวกัน (co-location) มักจะเป็น pod ที่ share data กันเป็นจำนวนมาก
Anti-affinity คือ pods เหล่านี้ต้องอยู่คนละ location กัน เหมาะกับ pods ที่ต้องการ fault tolerance

Operations ที่สามารถใช้ในการระบุ labels เช่น

In: เลือก pod ที่มี labels ที่มีค่าตามที่ระบุไว้
NotIn: เลือก pod ที่ไม่มี labels ที่มีค่าตามที่ระบุไว้
Exists: เลือก pod ที่มี labels ที่ระบุ
DoesNotExist: เลือก pod ที่ไม่มี labels ที่ระบุ

นอกจากนี้ ยังมีการระบุรายละเอียดการ schedule pods ลงไปอีก 2 parameters คือ

requiredDuringSchedulingIgnoredDuringExecution: ต้องมี labels ตาม conditions ที่กำหนดเท่านั้น ถ้าไม่มี ไม่ schedule (hard affinity)
preferredDuringSchedulingIgnoredDuringExecution: ถ้าไม่มี labels ตาม conditions ที่กำหนด ก็ไม่เป็นไร แต่ถ้ามีก็จะ schedule ตาม conditions ที่กำหนดนั้น (soft affinity)

มากไปกว่านั้น เรายังสามารถใช้ร่วมกับ topologyKey ได้อีกด้วย ดังนี้

ถ้าระบุ Affinity พร้อมกับ Anti-affinity ที่เป็น requiredDuringSchedulingIgnoredDuringExecution ต้องระบุ topologyKey
ถ้าระบุ Anti-affinity ที่เป็น requiredDuringSchedulingIgnoredDuringExecution เท่านั้น topologyKey ต้องเป็น kubernetes.io/hostname
ถ้าระบุ Anti-affinity ที่เป็น preferredDuringSchedulingIgnoredDuringExecution เท่านั้น topologyKey ต้องระบุ topologyKey
นอกเหนือจากข้างบน topologyKey เป็นค่าอะไรก็ได้ ใน built-in Labels

ตัวอย่าง

หากเราต้องการ deploy ของ Redis cluster ที่มี 3 replicas ซึ่งแต่ละ replica อยู่คนละ node กัน เพื่อเพิ่ม fault-tolerance deployment จะเป็นดังนี้

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

แต่ละ Pods ใน Deployment มี Labels เป็น app: store และใน podAntiAffinity ว่าไม่ให้อยู่ร่วมกับ pods ที่มี label app: store นั้นหมายความว่า ห้าม pod Redis นี้อยู่ร่วมกัน

# เนื่องจาก มี 3 nodes cluster ดังนั้นต้องทำการ untaint master ก่อน
$ kubectl taint nodes --all node-role.kubernetes.io/master-
node/kube-0001.novalocal untainted
taint "node-role.kubernetes.io/master" not found
taint "node-role.kubernetes.io/master" not found

$ cat > redis.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine
EOF

$ kubectl create -f redis.yaml
deployment.apps/redis-cache created
$ kubectl get pods -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP               NODE                  NOMINATED NODE   READINESS GATES
redis-cache-6bc7d5b59d-ngnsf   1/1     Running   0          33s   192.168.93.152   kube-0001.novalocal   <none>           <none>
redis-cache-6bc7d5b59d-swzjm   1/1     Running   0          33s   192.168.32.63    kube-0003.novalocal   <none>           <none>
redis-cache-6bc7d5b59d-vzs7h   1/1     Running   0          33s   192.168.52.66    kube-0002.novalocal   <none>           <none>

หากเราต้องการ deploy frontend ของ web ecommerce ที frontend และ redis ต้องอยู่ node เดียวกัน โดยแต่ละคู่ต้องอยูู่คนละ node กัน เพื่อเพิ่ม fault-tolerance deployment จะเป็นดังนี้

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.16-alpine

เราให้ pod ของ frontend มี label เป็น app: web-store โดย

ระบุ podAntiAffinity ด้วย label app: web-store ซึ่งหมายความว่า ห้าม frontend อยู่ร่วม node กัน
ระบุ podAffinity ด้วย label app: store ซึ่งหมายความว่า frontend ต้องอยู่ร่วมใน node เดียวกับ backend

$ cat > web-store.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.16-alpine
EOF

$ kubectl create -f web-store.yaml 
deployment.apps/web-server created
$ kubectl get pods -o wide
NAME                           READY   STATUS    RESTARTS   AGE    IP               NODE                  NOMINATED NODE   READINESS GATES
redis-cache-6bc7d5b59d-brsp5   1/1     Running   0          118s   192.168.52.67    kube-0002.novalocal   <none>           <none>
redis-cache-6bc7d5b59d-crgrb   1/1     Running   0          118s   192.168.93.153   kube-0001.novalocal   <none>           <none>
redis-cache-6bc7d5b59d-kp4kq   1/1     Running   0          118s   192.168.32.1     kube-0003.novalocal   <none>           <none>
web-server-75b987f474-4qggk    1/1     Running   0          10s    192.168.32.2     kube-0003.novalocal   <none>           <none>
web-server-75b987f474-jswff    1/1     Running   0          10s    192.168.52.68    kube-0002.novalocal   <none>           <none>
web-server-75b987f474-kkddh    1/1     Running   0          10s    192.168.93.154   kube-0001.novalocal   <none>           <none>

Node Affinity Rules

เหมือนกับ nodeSelector แต่เพิ่มเติมความสามารถของ affinity เช่น operators (In, NotIn, Exists, DoesNotExist) และ requiredDuringSchedulingIgnoredDuringExecution/preferredDuringSchedulingIgnoredDuringExecution เข้ามา

พร้อมกันนั้นก็มีแผนที่จะทำ requiredDuringSchedulingIgnoredDuringExecution เพิ่มด้วย ซึ่ง ถ้ามีการเปลี่ยน labels ของ nodes จะมีผลกับ pod ที่ run อยู่ด้วย

ตัวอย่าง

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

ถ้ามี node ที่มี label another-node-label-key: another-node-label-value pod นี้จะถูก schedule ไปยัง node นั้น แต่ถ้าไม่มีจะไปดู node ที่มี labels kubernetes.io/e2e-az-name: e2e-az1 หรือ kubernetes.io/e2e-az-name: e2e-az2

$ kubectl label nodes kube-0002.novalocal kubernetes.io/e2e-az-name=e2e-az2
node/kube-0002.novalocal labeled
$ kubectl get nodes --show-labels
NAME                  STATUS   ROLES    AGE   VERSION   LABELS
kube-0001.novalocal   Ready    master   88d   v1.17.1   (...)
kube-0002.novalocal   Ready    <none>   88d   v1.17.1   (...),kubernetes.io/e2e-az-name=e2e-az2,(...)
kube-0003.novalocal   Ready    <none>   88d   v1.17.1   (...)
$ cat > node-affinity.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0
EOF
$ kubectl create -f node-affinity.yaml 
pod/with-node-affinity created
$ kubectl get pods -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
with-node-affinity   1/1     Running   0          23s   192.168.52.69   kube-0002.novalocal   <none>           <none>

Taints

taints คือความสามารถของ node ในการที่จะไม่ให้ pod ที่ไม่เหมาะสม มา run ที่มันได้ โดย pod ที่ไม่มี toleration ต่อ taints ของ node จะไม่สามารถ schedule pod มา run ที่ node นั้นได้

taints จะมีลักษณะแบบนี้ key=value:effect โดย key กับ value เป็นค่าใดๆ ก็ได้ที่กำหนดโดย adminitrator และ effect มีให้เลือก 3 แบบคือ

NoSchedule: ห้าม schedule pod มายัง node โดย pod ที่ run อยู่ก่อน assign taints จะไม่ได้รับผลกระทบ
PreferNoSchedule: ถ้าหา node ที่เหมาะสมไม่ได้แล้วจริงๆ ก็ schedule pod มายัง node นี้ได้
NoExecute: pod ใหม่ก็ห้าม schedule มา pod เก่าก็ต้องอพยบไปที่อื่น โดยถ้า pod มี tolerationSeconds กำหนดอยู่มันจะรอจนกว่าจะครบ tolerationSeconds ถึงจะ อบยพออกไป

ถ้า node มีหลาย taints pods ที่มี tolerations ทุก taints ถึงจะมา run ใน node นั้นๆ ได้

# วิธีการเพิ่ม taints ให้กับ node
$ kubectl taint nodes node1 key=value:NoSchedule

# วิธีการลบ taints ออกจาก node
$ kubectl taint nodes node1 key:NoSchedule-

Tolerations

เป็นการใส่ความสามารถให้ pod ทนต่อ taints ของ node ได้ โดย ต้อง match ทั้ง key, value และ effect

ซึ่ง key และ value เราสามารถกำหนด tolerations ได้ด้วย 2 operators คือ

Exists: ถ้า tolerations ที่เรากำหนด มี key ตรงกับ taints ของ node ก็ถือว่า match แล้ว
```
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"
```
Equal: ต้องตรงทั้ง key และ value ถึงจะถือว่า match (default operator)
```
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"
```

ถ้าไม่ระบุ effect ถือว่า ทน (toleration) ได้ทุก effect ดังนั้น เราสามารถระบุ toleration level 999 ที่ทนทานได้แทนทุก taint ดังนี้

ระบุแค่ operator: Exists -> ทนได้ทุก taints
```
tolerations:
- operator: "Exists"
```
ระบุแค่ operator: Exists และ key: "key" -> ทนได้ทุก taints ที่มี key ตรงกัน
```
tolerations:
- key: "key"
  operator: "Exists"
```

ถ้า node มีหลาย taints pods ที่จะ schedule ได้ ต้องมี tolerations ครบทุก taints ถ้าไม่ครบ pods จะถูกปฏิบัติด้วย effect ของ taints ที่มีความแรงที่สุดที่ไม่ match

Use cases ของ taints และ toleration เช่น

Dedicated Nodes ที่เราจะ reserve ไว้ให้แค่บางกลุ่มของ users ใช้งาน
Nodes with Special Hardware

Custom Scheduler

ถ้า affinity, taints และ policies ยังไม่พอดับความต้องการของเรา เราสามารถสร้าง scheduler ของเราเองได้ โดยสามารถเข้าไปดูได้ที่ Github

เพื่อใช้ scheduler ใหม่ของเรา เราต้องระบุ scheduler name เข้าไปใน pod specification ด้วย ถ้าไม่ระบุจะใช้ default scheduler แต่ถ้าเราระบุ scheduler ผิด pod ของเราจะอยู่ในสถานะ Pending

เราสามารถดูข้อมูลของ scheduler และ information อื่นๆ ได้ด้วย kubectl get events

$ kubectl get events
LAST SEEN   TYPE     REASON      OBJECT      MESSAGE
41s         Normal   Killing     pod/nginx   Stopping container nginx
2s          Normal   Scheduled   pod/nginx   Successfully assigned default/nginx to kube-0003.novalocal
1s          Normal   Pulled      pod/nginx   Container image "nginx" already present on machine
1s          Normal   Created     pod/nginx   Created container nginx
1s          Normal   Started     pod/nginx   Started container nginx

Django เลือก template มา render อย่างไร และทำไม Best Practice ถึงถูก

8P Inc. — Tue, 07 Apr 2020 15:30:44 +0000

จากการลองเล่น framework ตัวหนึ่งชื่อ Django (จังโก้) เพื่อนำมาใช้ในการทำ Web GUI สำหรับ project หนึ่ง

พอลองเล่นมาถึง Writing your first Django app, part 3 เกิดงงเรื่อง directory structure ของ template ที่ต้องเป็น project_name/app_name/templates/app_name/ และการสั่ง render template ต้องอ้างอิงชื่อเป็น app_name/home.html ซึ่งเค้าบอกว่าเป็น Best Practice

ที่ผมงงคือ... ทำไม directory structure ต้องมี app_name ซ้ำ 2 ครั้งเลยล่ะ ครั้งเดียวมันน่าจะรู้แล้วไหม และ ตอนเรียก template มา render ก็ต้องใส่ app_name ข้างหน้าชื่อ template อีก ซึ่งเราทำที่ app นี้อยู่แล้วทำไม่ยังต้องระบุอีกล่ะ

OK! ถ้ามันเป็น Best Practice ความไม่ make sense ต้องมีคำอธิบาย

มาดูกัน ผมเจออะไร (ต้องบอกก่อนว่าผมเพิ่งหัดใช้นะครับ เรื่องนี้หลายคนอาจรู้อยู่แล้ว 😁)

ใน settings.py ของ Django ที่เป็น "DjangoTemplate" จะเป็นแบบนี้

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

เราจะสนใจ 2 parameters นี้ก่อนคือ

DIRS คือ path ที่เราต้องการให้ django ไปค้นหา เป็น list of strings (default = [])
APP_DIRS คือ เป็น boolean บอกว่าให้หา template ใน directory ของ app หรือ ไม่ (default = True)

โดย พฤติกรรมในการหา template ของ "DjangoTemplate" จะเป็นลำดับตามนี้

หาใน DIRS ก่อน โดยหาตามลำดับของ list ที่เรากำหนด
เช่น DIRS = ['path/to/template1', 'path/to/template2', 'path/to/template3'] จะหาตามลำดับดังนี้

/path/to/template1/
/path/to/template2/
/path/to/template3/
หาใน APP_DIRS โดยถ้าเราตั้งค่าเป็น True Django จะไปดูจาก ตัวแปร INSTALLED_APPS ใน settings.py ซึ่ง เป็น list of string เช่น INSTALLED_APPS = ['app-a', 'app-b', 'app-c'] Django จะหาตามลำดับของ list นี้ ดังนี้

/path/to/project/app-a/templates/
/path/to/project/app-b/templates/
/path/to/project/app-b/templates/

จากตัวอย่างข้างต้น ลำดับของ directory ที่ Django ใช้หา template คือ

/path/to/template1/
/path/to/template2/
/path/to/template3/
/path/to/project/app-a/templates/
/path/to/project/app-b/templates/ 👈 เราจะเขียน template ที่นี่
/path/to/project/app-b/templates/

ด้วย logic การทำงานแบบนี้ ถ้าเราเขียน template ที่ app-b ชื่อ home.html แล้วเราระบุ ชื่อ template ในการ render แค่ home.html ถ้าบังเอิญว่า app-a ก็มี home.html อยู่เช่นกัน มันจะไป render home.html ของ app-a แทน เพราะมันหาเจอก่อน

ด้วยพฤติกรรมการทำงานแบบนี้ เราจึงต้องทำตาม Best Practice โดยสร้าง sub directory ที่เป็นชื่อ app ใต้ directory templatate ของ app นั้นๆ ด้วย ดังนี้

/path/to/template1/
/path/to/template2/
/path/to/template3/
/path/to/project/app-a/templates/app-a/
/path/to/project/app-b/templates/app-b/ 👈 เราจะเขียน template ที่นี่
/path/to/project/app-b/templates/app-c/

และเวลาที่เราเรียก template มาใช้งานก็จะเรียกด้วยการระบุชื่อ template ดังนี้ app-b/home.html

ด้วยวิธีนี้ การ render จะไม่หยิบ template มาผิด app

LFS258 [9/15]: Ingress

8P Inc. — Mon, 30 Mar 2020 14:56:54 +0000

TL;DR

Ingress Overview: เป็น L7 load balancer หลักๆ มี GCE, Nginx, HAProxy และ Traefix เป็นต้น
Ingress Controller: เป็น controller ที่ monitor URI /ingresses ของ API server เพื่อนำมา configure rule
Nginx: เป็น Ingress Controller ที่ใช้ Nginx เป็น reverse proxy
Google Load Balancer Controller (GLBC): เป็น reverse proxy ของ Google ใช้งานได้บน Goole Cloud ทั้ง GCE และ GKE
Ingress API Resources: แสดง YAML file ในการสร้าง Ingress
Deploying the Ingress Controller: แสดงการ setup Nginx Ingress
Creating an Ingress Rule: สร้าง rule และทำสอบ Nginx Ingress
Multiple Rules: สร้าง rule แบบ multi-domain และทำสอบ
Intelligent Connected Proxies: คือ service mesh เช่น Istio, Enovy และ Linkerd

Ingress Overview

ใน article ก่อนหน้านี้ เราได้เรียนรู้เกี่ยวกับ Service ซึ่งใช้ในการ expose application ให้ client ที่อยู่นอก cluster ใช้งานได้ ในบทนี้เราจะเรียนรู้เกี่ยวกับ Ingress Controllers และ Rules ซึ่งทำหน้าที่เดียวกัน แต่ต่างกันที่ประสิทธิภาพ แทนที่จะต้องใช้ load balancer เป็นตัวช่วย Ingress สามารถทำแบบนั้นได้เลย ไม่ว่าจะเป็น route ตาม domain หรือ URI Path

Ingress Controllers ไม่ได้เป็นส่วนหนึ่งของ kube-controller-manager binary แต่มันจะมี controller เป็นของตัวเอง ซึ่งก็มีได้หลาย controller โดย controller จะใช้ Ingress Rules ในการจัดการกับ traffic ทั้งขาเข้าและขาออก

Ingress รองรับ 2 controllers หลัก คือ GCE และ nginx จริงๆ แล้ว tool อื่นที่ทำหน้าที่เป็น reverse proxy เช่น HAProxy และ Traefix ก็ใช้งานได้ โดยมันจะ route traffic มายัง Service ที่ on แบบ ClusterIP ได้เลยตาม Ingress Rule ที่เรา configure ไว้

Ingress Controller

Ingress Controller อยู่ใน networking.k8s.io/v1beta1 resource group เป็น daemon ที่ run ใน Pod ซึ่งจะคอย monitor การเปลี่ยนแปลงของ /ingresses บน kube-apiserver ถ้าหากพบการเปลี่ยนแปลง มันจะไป configure rules เพื่อ support ให้ โดย traffic ส่วนใหญ่จะเป็น HTTP วิธีนี้จะทำให้สามารถเข้าถึง Services ได้ โดยไม่ต้องสนใจว่า Pods นั้นถูก deploy ไว้ที่ node ไหน

เราสามารถ deploy Ingress Controller ได้มากกว่า 1 controller ใน cluster เดียวกัน traffic จะใช้ annotation ในการเลือก controller ทีละตัวจนกว่าจะพบตัวที่เหมาะสม

Nginx

การ deploy Nginx Controller สามารถดูตัวอย่างของหลากหลาย platform ได้จาก ingress-nginx

เราสามารถ configure Nginx Controller ได้ผ่านทาง ConfigMap และ Annotations แต่ถ้ายังไม่พอใจเราสามารถ configure จาก custom template ได้ด้วย

คุณสมบัติของ Nginx Controller

integrate กับ RBAC ได้ง่าย
ใช้ annotation kubernetes.io/ingress.class: "nginx"
ถ้าจะใช้เป็น L7 revere proxy ต้องระบุ proxy-real-ip-cidr ด้วย
ถ้าจะใช้ feature session affinity ต้อง bypass kube-proxy
ไม่ได้ใช้ conntrack ที่เกิดจาก DNAT ของ iptables
ถ้าจะให้ terminate TLS ให้ต้องระบุุ host field ด้วย

Google Load Balancer Controller (GLBC)

GLBC คือ GCE L7 load balancer controller ที่จัดการ external loadbalancers ด้วย Kubernetes Ingress API

ในสร้าง 1 Ingress ต้องมี cloud resource เหล่านี้

Global Forwarding Rule: เป็นตัว manage VIP ของ Ingress
TargetHttpProxy: เป็นตัว manage SSL certs และ proxy ระหว่าง VIP และ Backend
URL Map: routing rules
Backend Service: รวม หลายๆ Instance Groups เป็น 1 Service Node Port
Instance Group: VM ที่ เป็น kubernetes node

Pipeline เป็นแบบนี้

โดย

แต่ละ Backend Service ต้องทำการ health check ไปยัง NodePort ของ Service
แต่ละ port ของ Backend Service ต้องตรงกับ Instance Group
แต่ละ port ของ Backend Service จะถูก expose ผ่าน firewall บน GCE LB IP ranges (130.211.0.0/22 and 35.191.0.0/16)

ตอนนี้ Ingress สามารถใช้ TLS และ TLS termination ที่ port 443 และยังไม่ support SNI

Ingress API Resources

Ingress object ยังเป็น extension API มีตัวอย่าง YAML file ดังนี้

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ghost
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          serviceName: test
          servicePort: 80

เราสามารถ manage มันได้ดังนี้

$ kubectl get ingress
$ kubectl delete ingress <ingress_name>
$ kubectl edit ingress <ingress_name>

Deploying the Ingress Controller

ในการ deploy Nginx Ingress ทำได้ง่ายๆ โดย ดูได้จาก Github

ในตัวอย่างจะขอ install แบบ Bare-Metal โดยใช้ NodePort ดังนี้

# Install
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created
limitrange/ingress-nginx created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
service/ingress-nginx created

# Verify
$ kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx --watch
NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx   nginx-ingress-controller-7f74f657bd-9fm44   1/1     Running   0          82s

Creating an Ingress Rule

ทำการ create deployment และ expose service ที่ port 2368

$ kubectl create deployment ghost --image=ghost
deployment.apps/ghost created

$ kubectl expose deployment ghost --port 2368
service/ghost exposed

$ kubectl get svc
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/ghost        ClusterIP   10.107.189.29   <none>        2368/TCP   11s
service/kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    74d

$ kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
pod/ghost-577564ddbd-nfqrc   1/1     Running   0          178m

ทำการสร้าง ingress rule โดย request ที่เข้ามา domain เป็น "ghost.192.168.99.100.nip.io" ให้ส่งไปที่ service ghost

$ cat > ingress.yaml << EOF
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
    name: ghost
spec:
    rules:
    - host: ghost.192.168.99.100.nip.io
    http:
        paths:
        - backend:
            serviceName: ghost
            servicePort: 2368
EOF
$ kubectl create -f ingress.yaml
ingress.networking.k8s.io/ghost created

$ kubectl get ingress
NAME    HOSTS                         ADDRESS   PORTS   AGE
ghost   ghost.192.168.99.100.nip.io             80      20s

$ kubectl describe ingress/ghost
Name:             ghost
Namespace:        default
Address:          10.107.151.119
Default backend:  default-http-backend:80 (<none>)
Rules:
Host                         Path  Backends
----                         ----  --------
ghost.192.168.99.100.nip.io  
                                ghost:2368 (192.168.32.59:2368)
Annotations:
Events:
Type    Reason  Age    From                      Message
----    ------  ----   ----                      -------
Normal  CREATE  3m12s  nginx-ingress-controller  Ingress default/ghost
Normal  UPDATE  2m40s  nginx-ingress-controller  Ingress default/ghost

ทำการ test ดูซิว่าถ้า doamin เป็น ghost.192.168.99.100.nip.io จะวิ่งไปที่ service ghost หรือไม่ โดยถ้าไปใช่ต้องได้ page ที่มี title เป็น ghost
```
$ curl -v -H 'host: ghost.192.168.99.100.nip.io' http://10.107.151.119:80 -o /dev/null
<title>Ghost</title>
```

Multiple Rules

ทำการ create deployment ชื่อ nginx และ expose service ที่ port 80

$ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created

$ kubectl expose deployment nginx --port 80
service/nginx exposed

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
ghost        ClusterIP   10.107.189.29   <none>        2368/TCP   12m
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    74d
nginx        ClusterIP   10.106.200.39   <none>        80/TCP     29s

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
ghost-577564ddbd-nfqrc   1/1     Running   0          3h11m
nginx-86c57db685-vb6gk   1/1     Running   0          63s

ทำการ update ingress rule โดย เพิ่มให้ request ที่มี domain เป็น "nginx.192.168.99.100.nip.io" ให้ส่งไปที่ service nginx

$ cat > ingress-2.yaml << EOF
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
    name: ghost
spec:
    rules:
    - host: ghost.192.168.99.100.nip.io
    http:
        paths:
        - backend:
            serviceName: ghost
            servicePort: 2368
    - host: nginx.192.168.99.100.nip.io
    http:
        paths:
        - backend:
            serviceName: nginx
            servicePort: 80
EOF

$ kubectl apply -f ingress-2.yaml
ingress.networking.k8s.io/ghost configured

$ kubectl get ingress
NAME    HOSTS                                                     ADDRESS          PORTS   AGE
ghost   ghost.192.168.99.100.nip.io,nginx.192.168.99.100.nip.io   10.107.151.119   80      10m

$ kubectl describe ingress/ghost
Name:             ghost
Namespace:        default
Address:          10.107.151.119
Default backend:  default-http-backend:80 (<none>)
Rules:
Host                         Path  Backends
----                         ----  --------
ghost.192.168.99.100.nip.io  
                                ghost:2368 (192.168.32.59:2368)
nginx.192.168.99.100.nip.io  
                                nginx:80 (192.168.52.65:80)
Annotations:
kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"networking.k8s.io/v1beta1","kind":"Ingress","metadata":{"annotations":{},"name":"ghost","namespace":"default"},"spec":{"rules":[{"host":"ghost.192.168.99.100.nip.io","http":{"paths":[{"backend":{"serviceName":"ghost","servicePort":2368}}]}},{"host":"nginx.192.168.99.100.nip.io","http":{"paths":[{"backend":{"serviceName":"nginx","servicePort":80}}]}}]}}

Events:
Type    Reason  Age                  From                      Message
----    ------  ----                 ----                      -------
Normal  CREATE  10m                  nginx-ingress-controller  Ingress default/ghost
Normal  UPDATE  79s (x2 over 9m50s)  nginx-ingress-controller  Ingress default/ghost

ทำการ test ดูซิว่า
- ถ้า doamin เป็น ghost.192.168.99.100.nip.io จะต้องวิ่งไปที่ service ghost
- ถ้า doamin เป็น nginx.192.168.99.100.nip.io จะต้องวิ่งไปที่ service nginx
```
$ curl -s -H 'host: ghost.192.168.99.100.nip.io' http://10.107.151.119:80 | grep '<title>'
<title>Ghost</title>

$ curl -s -H 'host: nginx.192.168.99.100.nip.io' http://10.107.151.119:80 | grep '<title>'
<title>Welcome to nginx!</title>
```

Intelligent Connected Proxies

ในกรณีที่ต้องการ feaature ที่เพิ่มขึ้น เช่น service discovery, rate limiting, traffic management หรือ advanced metric เราต้องเปลี่ยนมาใช้ service mesh โดย มันจะประกอบด้วย edge proxy และ embeded proxy ซึ่งจะทำงานร่วมกันเพื่อจักการ traffic ตาม rules ที่มาจาก control plane ตัวอย่างของ service mesh เช่น

Envoy: เป็น proxy ที่มีการออกแบบแบบ modular และ extensible มักถูกใช้เป็น data plane ของ tool อื่นๆ ของ service mesh
Istio: เป็น tool ที่ช่วยเพิ่มความสามารถของ Envoy ด้วยการมี control plane ได้มากกว่า 1 ตัว เป็นตัวที่ทำให้ service mesh flexible ขึ้นและมี feature มากขึ้น
Linkerd: เป็นอีกหนึ่ง service mesh ที่ออกแบบมาให้่ใช้งานได้ง่าย เร็ว และ เบา

LFS258 [8/15]: Kubernetes Volumes and Data

8P Inc. — Mon, 23 Mar 2020 10:34:49 +0000

TL;DR

Overview: Volume มองง่ายๆ มันคือ hard disk ของ container มีทั้งแบบที่ถ้า Pods ตาย แล้ว data หาย (Ephemeral) และ data ไม่หาย (Persistent) โดย Kubernetes นั้น support storage หลายชนิด ที่เป็นแบบนั้นเพราะ มี FlexVolume และ CSI ซึ่งทำให้ vendor ต่างๆ สามารถพัฒนา library ที่ support product ของตนเองแล้วนำมาต่อกับ Kubernetes ได้เลย
Introducing Volumes: Kubernetes mount Volume ในระดับ Pods แสดงว่า container ต่างๆ ที่อยู่ใน Pods จะเห็น Volume เดียวกัน ขึ้นอยู่กับ container จะเลือกเอาอะไรไปใช้ การ access volume ขึ้นอยู่กับ Permission ที่เรากำหนดไว้ โดย Permission จะเป็นระดับ Node เช่น ReadWriteOnce, ReadOnlyMany และ ReadWriteMany
Volume Types: Kubernetes support backend storage ได้หลากหลายชนิด เรียกชนิดเหล่านั้นว่า StorageClass โดย StorageClass นี้เองจะเป็นคนไปคุยกับ backend storage เพื่อทำงานต่างๆ ให้
Volume Spec: แสดงการใช้งาน emptyDir ซึ่งเป็น StorageClass ที่เป็น Ephemeral Storage
Share Volumes: แสดงการใช้ 2 containers ที่อยู่ใน Pod เดียวกัน mount Volume เดียวกัน โดยจะเห็นว่าทั้ง 2 containers เห็น data เดียวกัน
Persistence Volumes and Volume Claims: ในการใช้งาน Persistent Volume ต้องสร้าง PV ก่อน จากนั้นสร้าง PVC เพื่อจองพื้นที่จาก PV มาใช้ จากนั้นจึงจะสามารถ attach ไปให้ Pods ใช้งานได้
Secrets: เป็นวิธีช่วยให้ Pods การเข้าถึง data ได้ โดย Secret จะถูก encode แบบ base64 โดย Pods สามารถใช้งาน Secret ได้ทั้งแบบ Volume และ Environment Variable
ConfigMap: เป็นวิธีช่วยให้ Pods การเข้าถึง data ได้ โดย ConfigMap เป็น plain textโดย Pods สามารถใช้งาน ConfigMap ได้ทั้งแบบ Volume และ Environment Variable

Overview

Volume ก็คือ storage นั่นเอง มองง่ายๆ มันคือ hard disk ของ container โดยทั่วไป ถ้า container ตายหรือ restart data ในนั้นก็จะหายไป ใน Kubernetes volume จะผูกอยู่กับ Pods ไม่ใช้ container ภายใน โดยถ้า Pods มี หลาย container อยู่ภายใน container นะเห็น volume และ data เดียวกัน

ถ้าไม่อยากให้ data หายสามารถใช้ Persistent Volumes ได้ ซึ่ง Pods จะต้องทำการ claim volume ผ่านทาง Persistent Volumes Claim

การเขียนหรืออ่านอะไรใน volume จะต้องทำผ่าน backend storage ซึ่งใน v1.17 รองรับถึง 28 ชนิด ไม่ว่าจะเป็น Ceph, NFS หรือ storage ของ cloud providers เจ้าต่างฟๆ ซึ่งอาจมีการ setting ต่างกันตามชนิดของ backend

Backend storage ของ kubernetes มี 2 แบบ คือ

in-tree: ส่วนใหญ่เป็นมากับ kubernetes มาอย่างยาวนาน โดย code จะถูก built, linked, compiled และ shipped มากับ core ของ Kubernetes เลย Backend ประเภทนี้ค่อยๆ ถูก migrate ไปเป็น out-of-tree
out-of-tree: หลังจากการมาของ FlexVolume ใน v1.2 และ Container Storage Interface (CSI) ใน v1.9 ทำให้ code ของ backend storage ไม่ต้องรวมอยู่ใน core ของ Kubernetes อีกต่อไป โดย เจ้าของ product สามารถ develop เองแล้วค่อยมาต่อกับ kubernetes ด้วยวิธีนี้ทำให้ core ของ kubernetes เบาขึ้น และ เจ้าของ product สามารถ fix bug หรือ เพิ่ม feature ได้เองโดยไม่ต้องรอมาก merge code กับ kubernets การทำงานก็จะเร็วขึ้น

นอกจากการใช้ volume ที่กล่าวข้างต้น ยังมีอีก 2 ทางในการนำ data เข้าไปยัง Pods นั่นคือ

Secret: เป็นการส่งข้อมูลที่ถูก encode แล้ว เข้าไปใน pods เช่น SSH Key หรือ HTTPS certification
ConfigMap: เป็นการส่งข้อมูลที่ไม่ถูก encode เข้าไปใน pods เช่น configuration file ต่างๆ

Introducing Volumes

ใน 1 Pods สามารถ mount ได้หลาย volume และสามารถคละ backend type ได้ และเนื่องจาก volume ถูก present ในระดับ Pod ดังนั้น ต่าง container กันสามารถเห็น volume เดียวกันได้ อาจใช้ท่านี้เพื่อใช้ในการทำ container-to-container communition

นอกจากนี้ Volume ยังสามารถถูกเข้าถึงได้จากหลายๆ pods พร้อมๆ กัน และสามารถให้สิทธิ์ที่แตกต่างกันได้ แต่เนื่องจาก volume ไม่มี concurrent checking ดังนั้น อาจเกิดปัญหา file corrupt หรือ locking ได้

ในการกำหนด access mode ต้องทำ 2 ทางคือ ที่ volume เอง และ ตอนที่ Pods request claim เข้ามา โดย request จะต้องไม่มากกว่าสิทธิ์ที่ volume กำหนดไว้ โดย access mode มี ดังนี้

ReadWriteOnce: อนุญาติให้อ่านและเขียนได้จาก node เดียวเท่านั้น (2 pods ที่อยู่ node เดียวกัน สามารถ read/write ได้พร้อมกัน แต่ pods ที่อยู่ต่าง node read/write ไม่ได้ จะได้ error FailedAttachVolume)
ReadOnlyMany: อนุญาติให้อ่านอย่างเดียว จากหลายๆ node พร้อมๆ กัน
ReadWriteMany: อนุญาติให้อ่านและเขียนได้จากหลายๆ node พร้อมๆ กัน

kubernetes จะจัดกลุ่มของ volume ที่มี permission เหมือนกันไว้ และ sort volume size จาก น้อยไปหามาก เมื่อมี request เข้ามาก็จะเลือก volume เหมาะสมที่สุดให้ไป

เมื่อมีการ request volume

API server ของ kubernetes จะ request ขอ storage ไปยัง StorageClass plugin และ StorageClass plugin จะเป็นคนไปคุยกับ backend storage เอง
kubelet จะ map raw devices กับ mount point ใน container แลัวทำเป็น symbolic link บน host node filesystem เพื่อให้ container ใช้งาน storage ได้

ถ้าเราไม่ระบุ StorageClass Kubernetes จะเลือก Storage อะไรก็ได้ที่เหมาะสมกับ size และ access mode ที่เราส่งไปกลับมาให้เรา

Volume Types

Kubernetes รองรับ Backend Storage ได้หลากหลาย บางอย่างใช้แค่ใน local บางอย่างต้องใช้งานผ่าน network ซึ่งแต่ละชนิดก็มีข้อดี ข้อเสีย แต่ต่างกันออกไป เรามาดูตัวอย่างกันซักหน่อย

GCEpersistentDisk: เป็นการ mount disk GCE บน Google Cloud Platform เข้าไปใน Pods
awselasticblockstore: เป็นการ mount disk EBS บน AWS เข้าไปใน Pods
emptyDir: เป็นการ mount empty directory ให้กับ Pods โดย volume จะเกิดและตายไปพร้อมกับ Pod
hostPath: เป็นการ mount resource จาก host เช่น file หรือ directoty ให้กับ Pods ซึ่งต้องมี resource ดังกล่าวอยู่ที่ host ก่อน ยกเว้น ถ้าเราใช้ option DirectoryOrCreate หรือ FileOrCreate ที่จะสร้าง resource ให้ Pods หากไม่มี
nfs: เป็นการ mount NFS (Network File System) ให้กับ Pods (เหมาะกับ multiple readers)
iscsi: เป็นการ mount iSCSI (SCSI over IP) ให้กับ Pods (เหมาะกับ multiple readers)
rbd: เป็นการ mount Rados Block Device ให้กับ Pods (เหมาะกับ multiple writers)
cephfs: เป็นการ mount CephFS volume ให้กับ Pods (เหมาะกับ multiple writers)
glusterfs: เป็นการ mount Glusterfs (an open source networked filesystem) ให้กับ Pods (เหมาะกับ multiple writers)

สามารถดู Backend Storage เพิ่มเติมได้จาก Official Doc

Volume Spec

ตัวอย่างการ mount volume ง่ายๆ คือ emptyDir โดย emptyDir คือ การสร้าง directory ภายใน container นั่นเอง ไม่ได้ไป mount ที่ไหน การเขียน data จะอยู่ใน shared container space ทำให้ไม่ persistence และ หายไปพร้อมกับการตายของ Pod

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    name: busy
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /scratch
      name: scratch-volume
  volumes:
  - name: scratch-volume
    emptyDir: {}

YAML file ข้างต้น เป็นการสร้าง Pod ที่มี 1 container และมี volume ชื่อ scratch-volume mount ไว้ที /scratch ภายใน container

สามารถทดสอบได้ดังนี้

$ cat > busybox-emptyDir.yml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    name: busy
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /scratch
      name: scratch-volume
  volumes:
  - name: scratch-volume
    emptyDir: {}
EOF
$ kubectl apply -f busybox-emptyDir.yml 
pod/busybox created
$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          9s
$ kubectl exec -it busybox -- sh
/ # df -h /scratch
Filesystem                Size      Used Available Use% Mounted on
/dev/mapper/rhel-var     60.0G      2.5G     57.5G   4% /scratch
/ # exit
$ kubectl delete -f busybox-emptyDir.yml 
pod "busybox" deleted

Share Volumes

จากที่เรารู้แล้วว่า container ใน pod เดียวกัน จะ share volume กัน หัวข้อนี้จะมาลงมือทำกันดู ก่อนอื่นมาดู YAML กันก่อน

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    name: busy
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /busy
      name: test
  - image: busybox
    name: box
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /box
      name: test
  volumes:
  - name: test
    emptyDir: {}

จาก YAML file ข้างต้น ใน pod มี 2 containers ชื่อ busy และ box โดย แต่ละ container mount volume ชื่อ test ไว้ที่ path /busy และ /box ตามลำดับ เดี๋ยวเราจะลองเขียนอ่าน file ดูกันว่ามันเห็นเหมือนกันไหม

$ cat > busybox-sharedVolume.yml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - image: busybox
    name: busy
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /busy
      name: test
  - image: busybox
    name: box
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /box
      name: test
  volumes:
  - name: test
    emptyDir: {}
EOF
$ kubectl apply -f busybox-sharedVolume.yml
pod/busybox created 
$ kubectl get pods
NAME      READY   STATUS    RESTARTS   AGE
busybox   2/2     Running   0          16s
$ kubectl exec -it busybox -c box -- touch /box/foobar
$ kubectl exec -it busybox -c busy -- ls /busy/
foobar
$ kubectl delete -f busybox-sharedVolume.yml
pod "busybox" deleted

Persistence Volumes and Volume Claims

Persistence Volumes (pv) คือ storage ที่ ถ้า pods ตาย data ก็ยังอยู่ การ assign volume ประเภทนี้ ให้กับ Pods จะต้อง define PersistentVolume ก่อน จากนี้ สร้าง persistenctVolumeClaim (pvc) เพื่อขอเฉือน volume มาให้ pod ใช้ จากนั้นจึงค่อย attach persistent volume ก้อนที่ claim มาให้กับ Pod

Lifecycle ของ volume และ claim มีดังนี้

Provisioning: เป็นการสร้าง PV โดยทำได้ทั้ง Static และ Dynamic
- Statics: admin create PV ทิ้งไว้ รอให้ users มา claim ไปใช้
- Dynamic: ถ้าไม่มี PV ไหน match กับ PVC เลย kubernetes จะ create PV ให้อันโนมัติ โดย cluster ต้องระบุ DefaultStorageClass ด้วย
Binding: อาจเป็นช่วงที่กำลัง match PVC กับ PV หรือ PV รอให้ StorageClass provision PV ขึ้นมา
Using: เป็นช่วงที่ Pods mount volume ไปใช้แล้ว
Releasing: เป็นช่วงที่ Pods ส่งคำสั่งไปเลิกใช้ PVC และทำการ delete PVC เมื่อ PVC ถูกลบไปแล้ว data อาจยังอยู่หรือถูกลบขึ้นอยู่กับ persistentVolumeReclaimPolicy
Reclaiming: เป็นช่วงหลังจากที่ PVC ถูก delete เรียบร้อย โดย มี 3 options คือ
- Retain: ยังเก็บ PV ไว้อยู่ ให้ admin เอาไปจัดการเอง
- Delete: ลบ PV และ Backend Storage ที่ allocate ให้ไปด้วยเลย
- Recycle: (deprecated แล้ว) ลบข้อมูลใน PVC ด้วย (rm -rf /thevolume/*) จากนั้นก็พร้อมสำหรับการถูก claim ใหม่

PV นั้นไม่ได้อยู่ใน namespace ใด namespace หนึ่ง แต่ PVC จะอยู่ได้แค่ namespace เดียวเท่านั้น

ตัวอย่างการ create PV ชื่อ task-pv-volume ซึ่งแบบ hostPath ขนาด 10 GB ใน mode ReadWriteOnce

$ cat > pv-volume.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
EOF
$ kubectl apply -f pv-volume.yaml 
persistentvolume/task-pv-volume created
$ kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Available           manual                  14s

ตัวอย่างการ create PVC ชื่อ task-pv-claim ซึ่ง เฉือนมาใช้ 3 GB ใน mode ReadWriteOnce

$ cat > pv-claim.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
EOF
$ kubectl apply -f pv-claim.yaml
persistentvolumeclaim/task-pv-claim created
$ kubectl get pv task-pv-volume
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Bound    default/task-pv-claim   manual                  6m23s
$ kubectl get pvc task-pv-claim
NAME            STATUS   VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
task-pv-claim   Bound    task-pv-volume   10Gi       RWO            manual         75s

จะเห็นว่า PVC เปลี่ยนจาก status "Available" เป็น "Bound"

ตัวอย่างการ attch PVC ไปยัง Pods

# ที่ Master Node
$ cat > pv-pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage
EOF
$ kubectl apply -f pv-pod.yaml
pod/task-pv-pod created
$ kubectl get pod task-pv-pod -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP              NODE                  NOMINATED NODE   READINESS GATES
task-pv-pod   1/1     Running   0          71s   192.168.32.51   kube-0003.novalocal   <none>           <none>

# login เข้าไปยังเครื่องที่ pods run อยู่ ในที่นี้คือ kube-0003.novalocal 
$ sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"
$ cat /mnt/data/index.html
Hello from Kubernetes storage

# กลับไปยัง Master Node
kubectl exec -it task-pv-pod -- /bin/bash
root@task-pv-pod:/# apt update
root@task-pv-pod:/# apt install curl
root@task-pv-pod:/# curl http://localhost/
Hello from Kubernetes storage
root@task-pv-pod:/# exit

# Clean up
$ kubectl delete pod task-pv-pod
pod "task-pv-pod" deleted
$ kubectl delete pvc task-pv-claim
persistentvolumeclaim "task-pv-claim" deleted
$ kubectl delete pv task-pv-volume
persistentvolume "task-pv-volume" deleted

# Login ไปยังเครื่องที่ สร้าง file ไว้ (kube-0003.novalocal)
$ sudo rm /mnt/data/index.html
$ sudo rmdir /mnt/data

Secrets

ถึงแม้ Pods จะสามารถเข้าถึง data ต่างๆ ด้วย volume แต่ก็มีบาง data ที่เราไม่อยากให้เห็นได้ด้วยตาเปล่า เช่น password หรือ certification จึงมี Secret เกิดขึ้นมา โดย Secret จะถูกเก็บในรูปแบบ base64-encoded (default)

แต่เราสามารถ configure ให้มัน encrypt ได้โดยการสร้าง EncryptionConfiguration ด้วย key และ identity ที่เหมาะสม จากนั้นทำการเพิ่ม flag --encryption-provider-config ที่ใช่ระบุวิธีการ encrypt เช่น "aescdc" หรือ "ksm" ให้กับkube-apiserver แล้วทำการ recreate Secret ใหม่ทั้งหมด

ในการเปลี่ยน key ต้องสร้าง key ใหม่ก่อน แล้วจึง restart kube-apiserver ทุกตัว จากนั้นจึง recreate Secret ใหม่ทั้งหมด

kubernetes ไม่ได้จำกับจำนวน Secret แต่ Secret ไม่ควรมีขนาดเกิน 1 MB โดย Secret จะถูกเก็บใน tmpfs ซึ่งเป็น memory ดังนั้นถ้ามีเยอะกินไปก็จะเปลือง memory ของ host

เราสามารถ create Secret ได้ดังนี้

Create ด้วย kubectl create secret command จาก file

$ echo -n 'admin' > username.txt
$ echo -n '1f2d1e2e67df' > password.txt
$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
secret/db-user-pass created
$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
db-user-pass          Opaque                                2      10s
$ kubectl describe secret/db-user-pass
Name:         db-user-pass
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password.txt:  12 bytes
username.txt:  5 bytes

Create ด้วย kubectl create secret command จากการ pass argument

$ kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb'
secret/dev-db-secret created
$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
dev-db-secret         Opaque                                2      4s
$ kubectl describe secret/dev-db-secret
Name:         dev-db-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
password:  11 bytes
username:  7 bytes

Create ด้วย YAML file แบบ manual

$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
$ cat > secret.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
EOF
$ kubectl apply -f secret.yaml
secret/mysecret created
$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
mysecret              Opaque                                2      15s
$ kubectl describe secret/mysecret
Name:         mysecret
Namespace:    default
Labels:       <none>
Annotations:  
Type:         Opaque

Data
====
password:  12 bytes
username:  5 bytes

Create ด้วย YAML file โดยใช้ stringData

$ cat > secret_config.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: config.yaml
type: Opaque
stringData:
config.yaml: |-
    apiUrl: "https://my.api.com/api/v1"
    username: "user"
    password: "password"
EOF
$ kubectl apply -f secret_config.yaml
secret/config.yaml created
$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
config.yaml           Opaque                                1      8s
$ kubectl describe secret/config.yaml
Name:         config.yaml
Namespace:    default
Labels:       <none>
Annotations:  
Type:         Opaque

Data
====
config.yaml:  73 bytes

เราสามารถใช้งาน Secret ได้ดังนี้

ใช้ในรูปแบบของ file ใน Pods

$ kubectl describe secret/mysecret
Name:         mysecret
Namespace:    default
Labels:       <none>
Annotations:  
Type:         Opaque

Data
====
password:  12 bytes
username:  5 bytes
$ cat > pod-with-mysecret-01.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
    image: redis
    volumeMounts:
    - name: foo
    mountPath: "/etc/foo"
    readOnly: true
volumes:
- name: foo
    secret:
    secretName: mysecret
EOF
$ kubectl apply -f pod-with-mysecret-01.yaml
pod/mypod created
$ kubectl exec -it mypod -- bash
root@mypod:/data# ls -l /etc/foo
total 0
lrwxrwxrwx. 1 root root 15 Mar 20 15:30 password -> ..data/password
lrwxrwxrwx. 1 root root 15 Mar 20 15:30 username -> ..data/username
root@mypod:/data# cat /etc/foo/username
admin
root@mypod:/data# cat /etc/foo/password
1f2d1e2e67df
root@mypod:/data# exit
$ kubectl delete -f pod-with-mysecret-01.yaml
pod "mypod" deleted

เราสามารถเลือก mount บาง file แล้วเปลี่ยนที่วาง และ ชื่อ file ด้วยได้ดังนี้

$ cat > pod-with-mysecret-02.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
    image: redis
    volumeMounts:
    - name: foo
    mountPath: "/etc/foo"
    readOnly: true
volumes:
- name: foo
    secret:
    secretName: mysecret
    items:
    - key: username
      path: my-group/my-username
EOF
$ kubectl apply -f pod-with-mysecret-02.yaml
pod/mypod created
$ kubectl exec -it mypod -- bash
root@mypod:/data# ls -l /etc/foo/my-group/my-username 
-rw-r--r--. 1 root root 5 Mar 20 15:35 /etc/foo/my-group/my-username
root@mypod:/data# cat /etc/foo/my-group/my-username
admin
root@mypod:/data# exit
$ kubectl delete -f pod-with-mysecret-02.yaml
pod "mypod" deleted

ใช้ในรูปแบบของ Environment Variable ใน Pods

$ cat > pod-with-mysecret-03.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never
EOF
$ kubectl apply -f pod-with-mysecret-03.yaml
pod/secret-env-pod created
$ kubectl exec -it secret-env-pod -- bash
root@secret-env-pod:/data# echo $SECRET_USERNAME
admin
root@secret-env-pod:/data# echo $SECRET_PASSWORD
1f2d1e2e67df
root@secret-env-pod:/data# exit
exit
$ kubectl delete -f pod-with-mysecret-03.yaml
pod "secret-env-pod" deleted

ConfigMap

ConfigMap เหมือน Secret เลย ยกเว้นแค่ไม่ได้ encode เราใช้ ConfigMap เพื่อแยก configuration file ออกมาจาก image ของ container เพื่อเวลาที่ต้องการแก้ไข configuration file จะได้ไม่ต้อง build image ใหม่ ซึ่งจะทำให้ version ของ image เพิ่มขึ้น โดยไม่ได้มีการแก้ไข code ด้วย

ConfigMap สามารถเก็บข้อมูลได้ทั้งในรูปแบบ key-value pair หรือ plain configuration file

เราสามารถสร้าง ConfigMap ได้ดังนี้

สร้างจาก Directory

$ mkdir -p configure-pod-container/configmap/
$ wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
$ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
$ ls -l configure-pod-container/configmap/
total 8
-rw-rw-r--. 1 admin admin 157 Mar 20 22:57 game.properties
-rw-rw-r--. 1 admin admin  83 Mar 20 22:57 ui.properties
$ kubectl create configmap game-config --from-file=configure-pod-container/configmap/
configmap/game-config created
$ kubectl describe configmaps game-config
Name:         game-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Events:  <none>
$ kubectl get configmaps game-config -o yaml
apiVersion: v1
data:
game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
creationTimestamp: "2020-03-20T15:58:20Z"
name: game-config
namespace: default
resourceVersion: "13587110"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: efe9fc42-4c19-495f-a0f1-91b59dc77431

สร้างจาก File

$ kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
configmap/game-config-3 created
$ kubectl describe configmaps game-config-3 
Name:         game-config-3
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game-special-key:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events:  <none>
$ kubectl get configmaps game-config-3 -o yaml
apiVersion: v1
data:
game-special-key: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
creationTimestamp: "2020-03-20T16:00:46Z"
name: game-config-3
namespace: default
resourceVersion: "13587478"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 03e19330-0498-43f3-baf6-fce9501398df

สร้างจาก literal values

$ kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
configmap/special-config created
$ kubectl describe configmaps special-config
Name:         special-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
special.how:
----
very
special.type:
----
charm
Events:  <none>
$ kubectl get configmaps special-config -o yaml
apiVersion: v1
data:
special.how: very
special.type: charm
kind: ConfigMap
metadata:
creationTimestamp: "2020-03-20T16:03:16Z"
name: special-config
namespace: default
resourceVersion: "13587836"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: 7d5636bb-a677-46dd-8f49-a60f35999357

เราสามารถใช้งาน ConfigMap ได้ดังนี้

Assign ConfigMap ไปยัง Environment Variable

$ kubectl create configmap special-config --from-literal=special.how=very
configmap/special-config created
$ cat > pod-single-configmap-env-variable.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
    - name: test-container
    image: redis
    env:
        - name: SPECIAL_LEVEL_KEY
        valueFrom:
            configMapKeyRef:
            name: special-config
            key: special.how
restartPolicy: Never
EOF
$ kubectl create -f pod-single-configmap-env-variable.yaml
pod/dapi-test-pod created
$ kubectl exec -it dapi-test-pod -- bash
root@dapi-test-pod:/data# echo $SPECIAL_LEVEL_KEY
very
root@dapi-test-pod:/data# exit
exit
$ kubectl delete -f pod-single-configmap-env-variable.yaml
pod "dapi-test-pod" deleted

add ConfigMap เป็น data ใน Volume

$ cat > configmap-multikeys.yaml << EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
EOF
$ kubectl create -f configmap-multikeys.yaml
configmap/special-config created
$ cat > pod-configmap-volume.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
    - name: test-container
    image: redis
    volumeMounts:
    - name: config-volume
        mountPath: /etc/config
volumes:
    - name: config-volume
    configMap:
        name: special-config
restartPolicy: Never
EOF
$ kubectl create -f pod-configmap-volume.yaml
pod/dapi-test-pod created
$ kubectl exec -it dapi-test-pod -- bash
root@dapi-test-pod:/data# ls -l /etc/config/
total 0
lrwxrwxrwx. 1 root root 20 Mar 20 16:25 SPECIAL_LEVEL -> ..data/SPECIAL_LEVEL
lrwxrwxrwx. 1 root root 19 Mar 20 16:25 SPECIAL_TYPE -> ..data/SPECIAL_TYPE
root@dapi-test-pod:/data# cat /etc/config/SPECIAL_LEVEL
very
root@dapi-test-pod:/data# cat /etc/config/SPECIAL_TYPE 
charm
root@dapi-test-pod:/data# exit
$ kubectl delete -f pod-configmap-volume.yaml
pod "dapi-test-pod" deleted
$ kubectl delete -f configmap-multikeys.yaml
configmap "special-config" deleted