Cloud-Native on Youqing Han - DevOps Engineer

Understanding kubectl apply Workflow

ihanyouqing#gmail.com (#->@) (Youqing Han) — Sun, 21 Sep 2025 10:00:00 +0800

Understanding kubectl apply Workflow

Kubernetes, as the de facto standard for container orchestration, has become the core infrastructure for modern cloud-native applications. This article provides an in-depth analysis of the kubectl apply workflow, core concepts, common production environment issues, and best practices to help DevOps engineers and SRE teams better understand and apply Kubernetes.

Deep Analysis of Kubernetes Workflows

kubectl apply Command Execution Flow

When executing the kubectl apply command, a series of complex interactions occur within Kubernetes. Let’s understand this process through a detailed sequence diagram:

Kubernetes Probes 解析：Liveness、Readiness 和 Startup Probes

ihanyouqing#gmail.com (#->@) (Youqing Han) — Mon, 15 Sep 2025 10:00:00 +0800

Kubernetes Probes 解析：Liveness、Readiness 和 Startup Probes

Kubernetes 探针（Probes）是确保容器健康运行的关键机制。正确配置和使用 Liveness、Readiness 和 Startup 探针对于生产环境的稳定性和可靠性至关重要。本文深入分析这三种探针的区别、应用场景以及检测成功和失败后的行为。

探针概述

Kubernetes 提供了三种类型的探针来监控容器的健康状态：

Liveness Probe（存活探针）：检测容器是否正在运行
Readiness Probe（就绪探针）：检测容器是否准备好接收流量
Startup Probe（启动探针）：检测容器应用是否已经启动

这三种探针可以独立配置，也可以组合使用，以满足不同应用场景的需求。

Liveness Probe 详解

定义与目的

Liveness Probe 用于检测容器是否仍在正常运行。如果容器处于运行状态但应用已经死锁或无法响应，Liveness Probe 会检测到这种情况并触发容器重启。

检测失败后的行为

当 Liveness Probe 失败时：

Kubernetes 会杀死容器
根据 Pod 的 restartPolicy 重启容器
如果 restartPolicy 为 Always 或 OnFailure，容器会被重启
如果 restartPolicy 为 Never，容器不会被重启

适用场景

应用可能进入死锁状态，需要重启恢复
应用可能因为内存泄漏或其他问题导致无响应
需要确保应用始终处于可用状态

配置示例

apiVersion: v1
kind: Pod
metadata:
  name: liveness-example
spec:
  containers:
  - name: app
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 30  # 容器启动后30秒开始检测
      periodSeconds: 10        # 每10秒检测一次
      timeoutSeconds: 5       # 检测超时时间5秒
      successThreshold: 1      # 连续1次成功视为成功
      failureThreshold: 3      # 连续3次失败视为失败

Readiness Probe 详解

定义与目的

Readiness Probe 用于检测容器是否准备好接收流量。只有当 Readiness Probe 成功时，Pod 才会被添加到 Service 的端点列表中，从而接收流量。

Building Cloud-Native Architecture: A Comprehensive Guide

ihanyouqing#gmail.com (#->@) (Youqing Han) — Fri, 22 Aug 2025 00:00:00 +0000

Introduction

Cloud-native architecture represents a paradigm shift in how we design, build, and deploy applications. It’s not just about running applications in the cloud—it’s about leveraging cloud capabilities to create applications that are scalable, resilient, and maintainable.

What is Cloud-Native Architecture?

Cloud-native architecture is an approach to building and running applications that fully exploit the advantages of the cloud computing model. Key characteristics include:

Microservices-based: Applications are broken down into small, independent services
Container-packaged: Applications are packaged in lightweight containers
Dynamically orchestrated: Services are actively scheduled and managed
API-driven: Services communicate through well-defined APIs

Microservices Design Patterns

Service Mesh Architecture

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: jason
      route:
        - destination:
            host: reviews
            subset: v2
    - route:
        - destination:
            host: reviews
            subset: v3

Circuit Breaker Pattern

package main

import (
    "github.com/sony/gobreaker"
    "time"
)

func createCircuitBreaker() *gobreaker.CircuitBreaker {
    return gobreaker.NewCircuitBreaker(gobreaker.Settings{
        Name:        "my-service",
        MaxRequests: 3,
        Interval:    10 * time.Second,
        Timeout:     60 * time.Second,
        ReadyToTrip: func(counts gobreaker.Counts) bool {
            failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
            return counts.Requests >= 3 && failureRatio >= 0.6
        },
    })
}

Container Orchestration with Kubernetes

Multi-Environment Deployment

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/myapp
    targetRevision: HEAD
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Infrastructure as Code with Terraform

Multi-Cloud Infrastructure

# AWS Configuration
provider "aws" {
  region = "us-west-2"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main-vpc"
    Environment = var.environment
  }
}

# Azure Configuration
provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "main" {
  name     = "rg-${var.environment}"
  location = var.location
}

Observability and Monitoring

Distributed Tracing with Jaeger

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200
  ingress:
    enabled: true
    hosts:
      - jaeger.example.com

Serverless Functions

AWS Lambda with Go

package main

import (
    "context"
    "encoding/json"
    "log"

    "github.com/aws/aws-lambda-go/lambda"
)

type Request struct {
    Name string `json:"name"`
}

type Response struct {
    Message string `json:"message"`
}

func HandleRequest(ctx context.Context, request Request) (Response, error) {
    log.Printf("Processing request for: %s", request.Name)

    return Response{
        Message: "Hello, " + request.Name + "!",
    }, nil
}

func main() {
    lambda.Start(HandleRequest)
}

Security Best Practices

Pod Security Standards

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
    - name: app
      image: nginx:alpine
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

Conclusion

Building cloud-native architecture requires a shift in mindset and approach. It’s not just about the technology—it’s about embracing principles of scalability, resilience, and maintainability.

Cloud-Native on Youqing Han - DevOps Engineer

Understanding kubectl apply Workflow

Understanding kubectl apply Workflow

Table of Contents

Deep Analysis of Kubernetes Workflows

kubectl apply Command Execution Flow

Kubernetes Probes 解析：Liveness、Readiness 和 Startup Probes

Kubernetes Probes 解析：Liveness、Readiness 和 Startup Probes

目录

探针概述

Liveness Probe 详解

定义与目的

检测失败后的行为

适用场景

配置示例

Readiness Probe 详解

定义与目的

Building Cloud-Native Architecture: A Comprehensive Guide

Introduction

What is Cloud-Native Architecture?

Microservices Design Patterns

Service Mesh Architecture

Circuit Breaker Pattern

Container Orchestration with Kubernetes

Multi-Environment Deployment

Infrastructure as Code with Terraform

Multi-Cloud Infrastructure

Observability and Monitoring

Distributed Tracing with Jaeger

Serverless Functions

AWS Lambda with Go

Security Best Practices

Pod Security Standards

Conclusion