結論: Docker Swarm の方が簡単ですが、K8s はより強力であり、業界標準です。

3.2。 Kubernetes と Apache Mesos

結論: Mesos はより柔軟ですが、より複雑です。 K8s はコンテナに重点を置いています。

3.3。 Kubernetes と Nomad

結論:Nomad はよりシンプルで、より多様なワークロードを備えていますが、エコシステムは小規模です。

3.4.いつ何を使用するか?_

_次の場合に Kubernetes を選択してください:

• ✅ 重要な本番ワークロード_
• ✅ 大規模にスケールする必要がある (100 以上)サービス)
• ✅ DevOps 経験のあるチーム
• ✅ 豊富なエコシステムが必要
• ✅ マルチクラウド戦略

Docker Swarm を選択時期:

• ✅ 小規模チーム、単一プロジェクトがシンプル
• ✅ 迅速にデプロイする必要がある
• ✅ Docker CLI に精通している
• ✅ 必要ありません規模が大きすぎる

次の場合に Nomad を選択してください:

• ✅ 多様なワークロード (コンテナーだけでなく)
• ✅ HashiCorp スタックを使用
• ✅ シンプルさが必要
• ✅ エッジ コンピューティング_

パート 4: Kubernetes アーキテクチャ概要_

4.1。 Kubernetes クラスター_

┌────────────────────────────────────────────────────────────┐
│                    KUBERNETES CLUSTER                      │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  ┌──────────────────────┐      ┌────────────────────────┐│
│  │   CONTROL PLANE      │      │      WORKER NODES      ││
│  │   (Master Nodes)     │      │                        ││
│  │                      │      │  ┌──────────────────┐  ││
│  │  ┌────────────────┐ │      │  │  Node 1          │  ││
│  │  │  API Server    │ │◄────►│  │  - kubelet       │  ││
│  │  └────────────────┘ │      │  │  - kube-proxy    │  ││
│  │                      │      │  │  - Container     │  ││
│  │  ┌────────────────┐ │      │  │    Runtime       │  ││
│  │  │  etcd          │ │      │  │  - Pods          │  ││
│  │  │  (Database)    │ │      │  └──────────────────┘  ││
│  │  └────────────────┘ │      │                        ││
│  │                      │      │  ┌──────────────────┐  ││
│  │  ┌────────────────┐ │      │  │  Node 2          │  ││
│  │  │  Scheduler     │ │      │  │  - kubelet       │  ││
│  │  └────────────────┘ │      │  │  - kube-proxy    │  ││
│  │                      │      │  │  - Container     │  ││
│  │  ┌────────────────┐ │      │  │    Runtime       │  ││
│  │  │  Controller    │ │      │  │  - Pods          │  ││
│  │  │  Manager       │ │      │  └──────────────────┘  ││
│  │  └────────────────┘ │      │                        ││
│  └──────────────────────┘      │  ┌──────────────────┐  ││
│                                 │  │  Node N          │  ││
│                                 │  │  ...             │  ││
│                                 │  └──────────────────┘  ││
│                                 └────────────────────────┘│
└────────────────────────────────────────────────────────────┘

4.2。コントロール プレーン コンポーネント (マスター)

1。 API サーバー 🚪

• Kubernetes の「ゲートウェイ」_
• すべての REST リクエストを処理_
• 認証と承認_
• リクエストの検証と処理
• etcd のフロントエンド_

kubectl → API Server → etcd
  ↑          ↓
  └──── Response

2。 etcd_ 💾

• Key-Value データベース
• クラスター状態全体の保存_
• 真実の情報源
• 高可用性 (HA) setup)_
• API サーバーのみが etcd_

3 と通信します。スケジューラ 📅

• Pod を実行するノードを決定
• リソース、制約、アフィニティを考慮_
• デプロイしない (kubelet)する)

Flow:
1. User tạo Pod
2. Scheduler xem Pods chưa assign
3. Chọn Node tốt nhất
4. Update Pod spec với nodeName

4。コントローラーマネージャー_ 🎮

• 複数のコントローラーを実行_
• _クラスター状態を監視_
• 目的の状態を達成するために変更を加える状態

重要なコントローラー:

• ノードコントローラー: ノードの健全性の監視
• _レプリケーションコントローラ_: ポッド番号が正しいことを確認してください
• エンドポイント コントローラ_: エンドポイント オブジェクトを設定
• ServiceAccount コントローラ: デフォルトを作成しますサービスアカウント_

4.3.ワーカー ノード コンポーネント_

1。 kubelet 👷_

• 各ノードでエージェントを実行_
• API サーバーからポッド仕様を取得_
• コンテナが実行されていることを確認 run_
• _レポートノード/ポッドのステータスを API サーバーに送信
• _liveness/readiness プローブを実行_

2。 kube-proxy_ 🔀_

• ノードごとのネットワーク プロキシ_
• ネットワーク ルールの維持_
• Kubernetes サービスの実装抽象化
• サービスの負荷分散
• モード: iptables、IPVS、ユーザースペース_

3。コンテナランタイム 🐳

• コンテナを実行するソフトウェア
• _Kubernetes CRI (コンテナ ランタイム インターフェイス) の実装
• 人気:
  • containerd (推奨)
  • CRI-O
  • Docker (K8s 1.24 以降では非推奨)

4.4。アドオン (オプションだが重要)

DNS (CoreDNS)

• サービス検出
• サービス名の解決IP
• 各サービスには DNS 名があります

ダッシュボード

• クラスター管理への Web UI_
• 視覚化リソース_

監視_ (メトリクスサーバー)_

• リソースメトリクスの収集
• CPU、メモリ使用法_
• HPA (水平ポッドオートスケーラー) を有効にする

ロギング

• EFK スタック (Elasticsearch、Fluentd、 Kibana)
• 集中ログ

_パート 5: KUBERNETES エコシステム

5.1。 CNCF ランドスケープ

Kubernetes は CNCF エコシステムの一部です:

┌─────────────────────────────────────────────┐
│         CNCF CLOUD NATIVE LANDSCAPE         │
├─────────────────────────────────────────────┤
│  Container Orchestration                    │
│  └─ Kubernetes ⭐                           │
│                                             │
│  Container Runtime                          │
│  └─ containerd, CRI-O                      │
│                                             │
│  Service Mesh                               │
│  └─ Istio, Linkerd, Consul                 │
│                                             │
│  Monitoring                                 │
│  └─ Prometheus, Grafana                    │
│                                             │
│  Logging                                    │
│  └─ Fluentd, Loki                          │
│                                             │
│  CI/CD                                      │
│  └─ Argo, Flux, Tekton                     │
│                                             │
│  Security                                   │
│  └─ Falco, OPA, Trivy                      │
└─────────────────────────────────────────────┘

5.2。コア ツール

パッケージ管理

• Helm: パッケージ マネージャーK8s
• カスタマイズ: 構成管理_

GitOps

• ArgoCD_: 宣言型 GitOps CD_
• Flux: GitOps ツールキット_

サービスメッシュ

• Istio: 完全なサービスメッシュ_
• _Linkerd: シンプル、軽量_

モニタリングと可観測性_

• Prometheus__: メトリクス収集
• Grafana:ビジュアリゼーション
• Jaeger: 分散トレース_

セキュリティ

• Falco_: ランタイムセキュリティ
• OPA: ポリシー エンジン
• Trivy: 脆弱性ユーティリティスキャナ

5.3。マネージド Kubernetes サービス

主要なクラウド プロバイダー:

• _AWS: EKS (Elastic Kubernetes)サービス)
• Google Cloud: GKE (Google Kubernetes Engine)
• Azure: AKS (Azure Kubernetes)サービス)
• IBM Cloud: IKS
• DigitalOcean: DOKS_
• Linode: LKE

ロイ便利:_

• コントロールプレーンマネージド_
• 自動アップグレード_
• クラウド サービスと統合
• 簡単なセットアップ_
• コスト: 有給労働者のみノード_

パート 6: KUBERNETES コンセプト担当者レポート

6.1。宣言型と命令型

命令型 (古い方法):

# Nói K8s phải làm GÌ và NHƯ THẾ NÀO
kubectl run nginx --image=nginx
kubectl expose deployment nginx --port=80
kubectl scale deployment nginx --replicas=3

宣言型 (方法K8s):

# Nói K8s muốn KẾT QUẢ gì
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80

kubectl apply -f nginx.yaml

宣言型が優れている理由:

• ✅ コードとしてのインフラストラクチャ
• ✅ バージョン管理フレンドリー_
• ✅冪等 (複数回実行 = 同じ結果)
• ✅ 自己修復
• ✅ 簡単なロールバック

6.2。望ましい状態と現在の状態

┌──────────────────────────────────────────────┐
│  KUBERNETES RECONCILIATION LOOP              │
├──────────────────────────────────────────────┤
│                                              │
│  ┌────────────────┐      ┌────────────────┐│
│  │ DESIRED STATE  │      │ CURRENT STATE  ││
│  │                │      │                ││
│  │ replicas: 3    │  VS  │ replicas: 2    ││
│  │ image: v2      │      │ image: v1      ││
│  └────────────────┘      └────────────────┘│
│          │                       │          │
│          └───────────┬───────────┘          │
│                      ↓                      │
│            ┌──────────────────┐             │
│            │   CONTROLLER     │             │
│            │   Takes Action   │             │
│            └──────────────────┘             │
│                      ↓                      │
│            ┌──────────────────┐             │
│            │  Start 1 Pod     │             │
│            │  Update 2 Pods   │             │
│            └──────────────────┘             │
└──────────────────────────────────────────────┘

永続的なコントローラー:

1. 現在の状態を監視
2. 望ましい状態と比較状態
3. 一致するアクションを実行
4. 繰り返し(調整ループ)

6.3.ラベルとセレクター

Labels = オブジェクトを整理するためのキーと値のペア_

metadata:
  labels:
    app: nginx
    tier: frontend
    environment: production
    version: v1.0

Selectors_ = 検索するクエリオブジェクト_

selector:
  matchLabels:
    app: nginx
    tier: frontend

ユースケース:

• サービスのポッド検索
• デプロイメントの管理ポッド_
• NetworkPolicy 適用ルール
• クエリとフィルタリング

パート 7: 動作中の KUBERNETES - 実際の例TE

シナリオ: 電子商取引ウェブサイト

要件:_

• フロントエンド: React アプリ (3)レプリカ)_
• バックエンド API: Node.js (5 reプリカ、自動スケール)_
• データベース: PostgreSQL (1 インスタンス、永続)
• キャッシュ: Redis (3 レプリカ)
• 高可用性
• ゼロダウンタイム更新_
• トラフィックに基づく自動スケーリング_

_Kubernetes はこれを解決します:

# Frontend Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: react-app
        image: myapp/frontend:v1.0
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"

Backend API with Auto-scaling
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
spec:
replicas: 5
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: api
image: myapp/backend:v1.0
ports:
- containerPort: 8080

Auto-scaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: backend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: backend
minReplicas: 5
maxReplicas: 20
metrics:

type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70


Database with Persistent Storage
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: postgres
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:14
ports:
- containerPort: 5432
volumeMounts:
- name: postgres-storage
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:

metadata:
name: postgres-storage
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 20Gi


Load Balancer Service
apiVersion: v1
kind: Service
metadata:
name: frontend-lb
spec:
type: LoadBalancer
selector:
app: frontend
ports:

port: 80
targetPort: 3000

Kubernetes自動:

• ✅ 3 フロントエンド + 5 バックエンド + 1 DB をデプロイ
• ✅ ノード間で分散
• ✅ 次の場合に再起動しますクラッシュ_
• ✅ トラフィック増加時にバックエンドを 5→20 にスケール
• ✅ ロードバランスリクエスト
• ✅ データベースの永続データ
• ✅ ローリング更新なしダウンタイム_

💡 主な要点_

留意すべき重要なポイント:

1. コンテナ オーケストレーションは次の問題を解決します。コンテナのスケーリングと管理_
   • 自動スケーリング、自己修復、負荷分散
   • サービス検出、ローリングアップデート
2. Kubernetes業界標準
   • Google による実証済み
   • 最大のコミュニティ
   • ベンダーagnostic_
3. K8s アーキテクチャには 2 つの主要部分があります:
   • コントロール プレーン: API サーバー、etcd、スケジューラ、コントローラ
   • ワーカーノード: kubelet、kube-proxy、コンテナランタイム
4. 宣言型 >命令的
   • 望ましい状態を宣言
   • K8 が自動的に調整
5. Richエコシステム
   • CNCF 景観
   • あらゆるニーズに対応するツール_
   • マネージド サービス利用可能

🎯 演習_

演習 1: 調査と比較比較

学習する_

• Kubernetes
• Docker Swarm
• Amazon 間の詳細な比較 (200 ～ 300 ワード) を書きます。 ECS

使いやすさ、拡張性、エコシステム、コストに重点を置きます。

演習 2: マインドマップ

マインドマップを描く (ツールまたは手を使用できます)概要:

• Kubernetes アーキテクチャ
• すべてのコンポーネントを含む
• 各コンポーネントの役割の説明

演習 3: ユースケース分析

作業中のアプリケーションを選択するか、知っている:

• 現在のアーキテクチャについて説明
• K8s に導入する場合の図を描く
• 利点と課題のリスト

演習4: ビデオ学習

ビデオ「100 秒でわかる Kubernetes」と「15 分でわかる Kubernetes」をご覧ください

• 5 つの主要なポイントのまとめ
• さらに詳しく学ぶために、理解できない点に注意してください詳細_

📖 参考文献_

記事を書く_

• Kubernetes 公式ドキュメント -概念_
• CNCF Kubernetes の概要
• 子供向け図解ガイドKubernetes

ビデオ_

• 5 つの Kubernetes分
• 100 で説明する Kubernetes秒_

インタラクティブ_

• Kubernetes で遊ぶ_
• Katacoda Kubernetes のシナリオ_

⏭️ 次の投稿_

レッスン 2: インストールと構成Kubernetes

次のレッスンでは、

• Minikube と kubectl のインストール
• 最初のレッスンを開始しますクラスター_
• Kubernetes ダッシュボードを探索_
• 基本的な kubectl コマンドを実行_
• kubeconfig について_

標準デバイス:

• 4GB 以上の RAM を搭載したコンピューター_
• Docker のインストール_
• VirtualBox またはVMware