YOOANT

접근제어

YOOANT — Sun, 17 May 2026 14:49:48 +0900

シェルおよびスクリプト

YOOANT — Sat, 16 May 2026 17:59:35 +0900

CLI관점에서 리눅스와 상호 작용하는 방법은 두 가지가 있다.

첫 번째 방법은 수동이다.

즉 사 용자가 터미널 앞에 앉아 대화식으로 명령을 입력하고 출력값을 받는 것이다. 이런 즉흥적인 상호 작용은 다음과 같이 매일 셸에서 수행하는 대부분의 작업에 해당한다.

디렉터리 몰록 출력, 파일 찾기, 파일 내부 내용 찾기
디렉터리 간 혹은 원격 시스템 간 파일 복사
이메일이나 뉴스를 읽거나 터미널에서 트윗 보내기

두 번째 방법은 셸이 해석하고 차례로 실행할 수 있는 특수한 종류의 파일에 있는 일련의 명령을 자동으로 처리하는 것이다.

이 모드를 일컬어 흔히 셸 스크립팅 또는 그냥 스클립팅 이라고 한다.

▪️터미널

터미널, 또는 터미널 에뮤레이터, 또는 소프트 터미널로 불린다.

터미널은 텍스트로 된 사용자 인터페이스(UI)를 제공하는 프로그램이다. 즉 터미널은 키보드에서 문자를 읽어 화면에 표시하는 기능을 지원한다. 기본적인 문자 중심의 입려과 출력 외에도 터미널은 커서, 화면 처리, 그리고 잠재적으로 색상 지원이 가능하도록 이스케이프 시퀀스 또는 이스케이프 코드를 지원한다. 예를 들어 Ctrl+H를 누르면 백스페이스가 실행되어 커서 왼쪽에 있는 문자가 삭제된다.

▪️셸

터미널 내부에서 실행되며 명령 ①인터프리터 역할을 하는 프로그램이다. 셸은 스트림을 통해 입력,출력을 처리하고, 변수를 지원하며, 사용 가능한 내장 명령이 몇 가지 있으며, 명령 실행 및 상태를 처리하고, 일반적으로 대화식 사용과 스크립트 사용을 모두 지원한다.

본셸(sh)이 많이 쓰였지만, 최근에는 배시셸(bash)가 많이 쓰인다.

①명령어 한 줄 입력하면, 그 즉시 읽어서 실행해버리는 방식. 엔터를 치는 순간 셸인터프리터가 그 명령을 해석해서 커널에게 요청한다.

1.스트림

입력과 출력, 줄여서 I/O라고 한다.프로그램에 어떻게 입력을 제공할 수 있을까? 프로그램의 출력값과 터미널이나 파일에 도달하는 위치를 어떻게 제어할까?

먼저, 셸은 입력과 출력을 위한 세 가지 기본 파일 디스크립터를 모든 프로세스에 제공한다.

stdin（FD 0）
stdout（FD 1）
stderr（FD 2）

셸이 제공하는 기본값을 사용하지 않으려면(예: stderr이 화면에 출력되지 않고 파일에 저장하려는경우) 스트림을 재지정 할 수 있다.

// stdout과 stderr을 모두 /dev/null로 재지정해 모든 출력값을 버린다.
$ curl https://example.com &> /dev/null

// 출력값과 상태값을 다른 파일로 재지정한다.
$ curl https://example.com > /tmp/content.txt 2> /tmp/curl-status

/tmp/content.txt

/tmp/curl-status

// 대화식으로 값을 입력하고 파일에 저장한다. Ctrl+D를 사용해 캡처를 중지하고 콘텐츠를 저장한다.
$ cat > /tmp/interactive-input.txt

/tmp/interactvie-input.txt

// stdin에서 값을 읽는 tr 명령을 사용해 모든 단어를 소문자로 만든다.
$ tr < /tmp/curl-status [A-Z] [a-z]

// curl을 사용해 URL을 다운로드하고 stderr에서 출력하는 상태값을 버린다. curl의 stdout값은 -l 옵션을 사용하여 행의 개수를 계산하는 wc의 stdin에 제공된다.
$ curl https://example.com 2> /dev/null | \
wc -l

2.변수

셸과 관련해 자주 접하게 되는 용어가 변수다. 값을 하드코딩하고 싶지 않거나 불가능할 때는 언제든 변수를 사용해 값을 저장하고 변경할 수 있다.

리눅스가 노출하는 구성 항목을 처리하려는 경우(예: 셸이 $PATH 변수에 저장된 실행 파일을 찾는 위치). 이는 변수를 읽기/쓰기할 수 있는 일종의 인터페이스다.
스크립트에서 사용자에게 값을 대화 형식으로 질문하려는 경우
긴 값을 한 번 정의해 입력을 줄이려는 경우(예:HTTP API의 URL).이 사용 사례는 변수를 선언한 후 값을 변경하지 않기 때문에 대략적으로 프로그램 언어의 const값에 해당한다.

변수는 다음과 같이 두 가지 종류로 나뉜다.

2-1.환경변수

셸 전체의 설정. env 명령어로 목록을 나열한다.

2-2.셸 변수

현재 실행 상황에서 유효하다. bash에서 set 명령어로 목록을 나열할 수 있다. 하위 프로세스는 셸 변수를 상속하지 않는다.

bash에서 export 명령어를 사용해 환경변수를 만들 수 있다. 변수의 값에 접근하고 싶을 때는 앞에 $를 붙이고, 변수를 제거하고 싶을 때는 unset을 사용한다.

// MY_VAR이라는 셸 변수를 생성하고 값을 42로 지정한다.
$ MY_VAR=42
// 셸 변수를 나열하고 MY_VAR를 필터링한다.
$ set | grep MY_VAR

// MY_GLOBAL_VAR이라는 새 환경변수를 만든다.
$ export MY_GLOBAL_VAR="fun with vars"

// 셸 변수를 나열하고 MY_로 시작하는 모든 변수를 필터링해본다. 예상대로 이전 단계에서 만든 두 변수가 모두 표시된다.
$ set | grep 'MY_*'
// 환경변수를 나열한다. 예상대로 MY_GLOBAL_VAR이 표시된다.
$ env | grep 'MY_*'

// 새 셸 세션, 즉 MY_VAR를 상속하지 않은 현재 셸 세션의 자식 프로세스를 만든다.
$ zsh (MacOS)
$ bash
// 현재 자식 프로세스에 있기 때문에 셸 변수를 나열하면 MY_GLOBAL_VAR만 나온다.
$ set | grep "MY_*"

3.종료상태

셸은 종료 상태 라고 하는 것을 사용해 명령 실행 완료를 명령 호출자에게 알린다. 일반적으로 리눅스 명령은 종료될 때 상태를 반환한다.

종료 상태값 0은 명령이 오류 없이 성공적으로 실행됐음을 의미하는 반면, 1에서 255 사이의 값은 실패를 나타낸다. 종료 상태를 확인 하려면 echo $?를 사용한다.

4.내장명령어

셸에는 여러 내장 명령어가 있다. 몇 가지 유용한 예로는 yes,echo,cat,read가 있다. help명령어를 사용하면 내장 명령어 목록을 나열할 수 있다. 그러나 그 외 모든 것은 보통 /usr/bin(사용자 명령의 겨우)이나 /usr/sbin(관리 명령의 경우)에 있는 셸 외부 프로그램이라는 점을 기억하자. 실행 파일을 어디에서 찾을지 어떻게 알 수 있을까? 다음과 같은 몇 가지 방법이 있다.

$ which ls

$ type ls

5.작업제어

작업제어는 대부분의 셸이 지원하는 기능이다. 기본적으로 명령을 입력하면 그 명령은 일반적으로 화면과 키보드를 제어하며, 이를 '포어그라운드에서 실행된다'고 한다.

// 명령 끝에 &를 넣으면 백그라운드에서 명령이 실행된다.
$ watch -n 5 "ls" &

// 모든 작업(job)의 목록을 출력한다.
$ jobs

// fg명령을 사용하면 프로세스를 포어그라운드로 가져올 수 있다. watch 명령을 종료하려면 Ctrl+C를 사용한다.
$ fg

▪️일반작업

1.자주 사용하는 명령어 단축하기

인터페이스의 기본 개념 중 한 가지는 가장 자주 사용하는 명령은 빠르게 입력해야 하므로 최소한의 노력만 들여야 한다는 것이다.

나의 경우에는 쿠버네티스의 "kubectl"을 많이 사용하기 때문에, "kubectl" 대신 "k"를 입력한다. 이런 방법을 일컬어 배시 셸에서는 앨리어스라고 부른다.

2.행 탐색과 조작

셸 프롬포트에 명령을 입력할 때는 행을 탐색하거나 행을 조작하는등 다양한 작업을 하곤 한다. 하기의 표는 일반적으로 사용되는 셸의 단축키 목록이다.

동작	명령어	비고
행의 시작으로 커서 이동	Ctrl+a
행의 마지막으로 커서 이동	Ctrl+e
커서를 한 문자 앞으로 이동	Ctrl+f
커서를 한 문자 뒤로 이동	Ctrl+b
커서를 한 단어 앞으로 이동	Alt+f	왼쪽 Alt 키에서만 작동
커서를 한 단어 뒤로 이동	Alt+b
현재 문자 삭제	Ctrl+d
커서 왼쪽 문자 삭제	Ctrl+h
커서 왼쪽 단어 삭제	Ctrl+w
커서 오른쪽의 모든 항목 삭제	Ctrl+k
커서 왼쪽의 모든 항목 삭제	Ctrl+u
화면 지우기	Ctrl+l
명령어 취소	Ctrl+c
실행 취소	Ctrl+_
기록 검색	Ctrl+r
검색 취소	Ctrl+g

3.파일 내용 관리

단 한 행의 텍스트를 추가하기 위해 매번 vi 같은 편집기를 실행하고 싶지는 않을 것이다. 또한 가끔은 편집기 사용이 불가능할 때도 있다. 하기는 텍스트 내용을 조작하는 몇 가지 방법이다.

// echo 출력을 재지정해 파일을 생성한다.
$ echo "First line" > ./something

// >> 연산자를 사용해 파일에 한 행을 추가한 후 내용을 확인한다.
$ echo "Second line" >> ./something && \
cat something

// sed를 사용해 파일 내용을 바꾸고 stdout으로 출력한다.
$ sed 's/line/LINE/' ./something

// here 문서를 사용해 파일을 생성한다.
$ cat << 'EOF' > ./another
First line
Second line
Thrid line
EOF

// 생성한 파일의 차이점을 보여준다.
$ diff -y ./something ./another

4.긴 파일 보기

긴 파일, 즉 셸의 한 화면에 표시할 수 없을 만큼 행 수가 많은 파일의 경우 less 또는 bat과 같은 페이저를 사용할 수 있다.페이지 나누기 기능을 활용하면 프로그램은 출력을 분할해서 화면에 나타낼 수 있는 분량에 맞게 페이지를 나눠 표시하고, 각 페이지를 탐색할 수 있는 명령어를 제공한다.

긴 파일을 처리하는 또 다른 방법은 예를들어 처음 몇 행처럼 파일의 선택 영역만 표시하는 것이다. 이럴 때 편리하게 쓸 수 있는 명령은 두 가지가 있다. 바로 head와 tail이다.

$ for i in {1..100} ; do echo $i >> ./longfile ; done
$ head -5 ./longfile

// tail을 이용해 로그의 파일의 마지막을 출력한다. -f 옵션은 따르다(follow)라는 의미로, 결과를 지속적으로 확인하거나 자동 업데이트함을 의미한다.
$ sudo tail -f <log파일등>

5.날짜와 시간 처리

date 명령은 고유한 파일 이름을 생성할 때 유용하다. 유닉스 타임스탬프등 여러 형식으로 날짜를 생성하고 다양한 날짜와 시간 형식 간에 변환할 수도 있다.

// 유닉스 타임스탬프를 생성한다.
$ date +%s

// 유닉스 타임스탬프를 사람이 읽을 수 있는 날짜로 변환한다.
$ date '+%Y/%m/%d %H:%M:%S'

▪️스크립팅

ExternalName

YOOANT — Wed, 13 May 2026 23:45:24 +0900

NodePort、LoadBalancer

YOOANT — Tue, 12 May 2026 21:56:36 +0900

1.NodePort

セレクター（spec.selector）とテンプレート（spec.template.metadata.labels）は、必ず一致していなければならない。Deploymentはこのセレクターを通じて、自分が管理すべきPodを探し出すからだ。もしこれらが異なっていると、デプロイ時にバリデーションエラー（Validation Error）が発生する。
一つのYAMLファイル内に複数のリソース（DeploymentやServiceなど）を定義する場合、「---」（ダッシュ3つ）は必須である。
Serviceの spec.selector は、Deploymentによって生成されたPodのラベル（template.metadata.labels）を指す必要がある。Deployment自体のラベルではなく、「Pod」のラベルであるという点が核心だ。なぜなら、ServiceはDeploymentという「管理者」を見るのではなく、実際に稼働している「Pod」たちを直接見ているからである。

2.LoadBalancer

Port-forward、HostPort、hostNetwork

YOOANT — Sun, 10 May 2026 19:31:36 +0900

1.手軽にアプリを公開する方法。

1-1.Port-forward

1-1-1.検証pod作成

apiVersion: v1
kind: Pod
metadata:
  name: fwd-chk-hn
spec:
  containers:
  - name: chk-hn 
    image: sysnet4admin/chk-hn

1-1-2.pod確認

1-1-3.port-forward設定

・Terminal①
# k port-forward fwd-chk-hn 8080:80

1-1-4.動作確認

・Terminal②

・Terminal①

※port-forwardは運用（Production）のためのツールではなく、徹底して「デバッグ」や「開発」のための、一時的な通信路である。

1-2.Hostport

1-2-1.検証pod作成

apiVersion: v1
kind: Pod
metadata:
  name: hp-chk-hn 
spec:
  containers:
  - name: chk-hn
    image: sysnet4admin/chk-hn
    ports:
    - containerPort: 80
      hostPort: 8080

1-2-2.pod確認

1-2-3.動作確認

※この方式で検証を行うには、Podがどのノードに配置されたかを把握し、該当ノードのIPアドレスを特定する必要がある。

したがって、hostportは（実用的には）使用できず、概念として残るのみとなっている。

①配置ノードの確認

②k8s-worker-1のIP確認

③通信確認

1-3.HostNetwork

1-3-1.検証pod作成

apiVersion: v1
kind: Pod
metadata:
  name: hnet-chk-hn
spec:
  hostNetwork: true
  containers:
    - name: chk-hn
      image: sysnet4admin/chk-hn

1-3-2.pod確認

1-3-3.動作確認

※この方式で検証を行うには、Podがどのノードに配置されたかを把握し、該当ノードのIPアドレスを特定する必要がある。

したがって、hostNetworkは（実用的には）使用できず、概念として残るのみとなっている。

①配置ノードの確認

※hostNetworkはノードのIPを占有して使用するため、PodのIPはPodが配置されたノードのIP（ホストIP）となる。

②k8s-worker-1のIP確認

③通信確認

※これまで扱った port-forward、hostPort、hostNetwork は、すべて「特定のノード」や「特定のポッド」に強く依存した方式である。実務（運用環境）では、ポッドがダウンして別のノードに再配置されることもあれば、ノードが数十台に及ぶこともあるため、これらの方式では対応が不可能だ。したがって、これらを補完しシステム化したものが、先に述べた Service (NodePort, LoadBalancer) や Ingress である。

DaemonSet、StatefulSet

YOOANT — Sat, 9 May 2026 22:55:38 +0900

1.DaemonSet

クラスター内の全ノード（または特定のノード）に、Podを必ず一つずつデプロイするリスーすである。

DaemonSetとDeploymentを比較すると、replicasの有無を除けば構成は同一である。

1-1.DaemonSet作成

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: ds-nginx 
  name: ds-nginx
spec:
  selector:
    matchLabels:
      app: po-nginx 
  template:
    metadata:
      labels:
        app: po-nginx
    spec:
      containers:
      - name: nginx 
        image: nginx

1-2.動作確認

①replicasが設定されていないにもかかわらず、Podが各ワーカーノードにデプロイされた。

※新規ワーカーノードが追加された場合、DaemonSetによって新規ノードにも自動的にデプロイされる。

2.StatefulSet

Podごとに「固有の識別子（名前）」と「専用ストレージ（データ）」を付与し、再起動してもそれらが維持されるように管理するリソースである。

StatefulSetとDeploymentを比較すると、serviceNameの有無を除けば構成は同一である。
serviceNameの指定は強制ルール（必須項目）である。
StatefulSetでデプロイすると、Podは正確な順序に基づいた固定の名前を持つ。
k8sエコシステムにおいて、唯一「状態（ステート）」を持つ独立した存在である。

2-1.StatefulSet作成

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sts-chk-hn
spec:
  replicas: 3
  serviceName: sts-svc-domain #statefulset need it
  selector:
    matchLabels:
      app: sts
  template:
    metadata:
      labels:
        app: sts
    spec:
      containers:
      - name: chk-hn
        image: sysnet4admin/chk-hn

2-2.動作確認

①0番から順に（順次）生成された。

②scaleoutすると、順次（順番に）増えていく。

③scaleinすると、順次（順番に）減っていく。

Job、CronJob

YOOANT — Sat, 9 May 2026 17:18:35 +0900

1.Job

1-1.成功jobおよび動作確認

1-1-1.事前準備としてnginxおよびserviceを作成

# Job確認の事前準備としてnginxとsvcを生成
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx 
spec:
  selector:
    run: nginx  
  ports:
    - name: http
      port: 80
      targetPort: 80
  type: ClusterIP

1-1-2.作成確認

1-1-3.Job作成

apiVersion: batch/v1
kind: Job
metadata:
  name: job-curl-succ
spec:
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk",  "nginx"]
      restartPolicy: Never

1-1-4.動作確認

1-1-2에서 확인했듯이 nginx와 서비스가 동작중이고 정상적으로 상태확인이 성공했다.

1-2.失敗jobおよび動作確認

1-2-1.Job作成

apiVersion: batch/v1
kind: Job
metadata:
  name: job-curl-fail
spec:
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk",  "hwan"]  // nginxではなく、hwanを入力
      restartPolicy: Never

1-2-2.動作確認

hwan은 동작중이지 않다는 에러메세지가 출력됐다.

1-3.job作成失敗および動作確認

1-3-1.Job作成

apiVersion: batch/v1
kind: Job
metadata:
  name: job-make-fail
spec:
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk",  "nginx"]
                                         // restartPolicyを削除

1-3-2.動作確認

※JobにおいてrestartPolicyをOnFailureまたはNeverに設定しなければならないという、k8sの強制的なルールがある。

Jobは「一度タスクを完了すれば終了（Exit）する」ことが目的であり、Alwaysを使用するとタスクが終わっても再実行を繰り返す無限ループに陥るためである。

したがって、Jobの本質（バッチ作業の完了可否）を明確に管理するために、podを新しく立ち上げるか（Never）、内部で再起動するか（OnFailure）を選択させる仕組みになっている。

1-4 .job並列実行および動作確認

1-4-1.Job作成

completions：実行量

※completionsが3の場合、Jobが成功したとみなされるためには、計3つのPodが順次実行され、正常に終了する必要がある。

apiVersion: batch/v1
kind: Job
metadata:
  name: job-completions 
spec:
  completions: 3 // 3つのPodが順次実行される。
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk",  "nginx"]
      restartPolicy: Never

1-4-2.動作確認

podのAGEを見ると順次実行されたことが分かる。

1-4-3.Job作成

parallelism：並列性／並行性

kind: Job
metadata:
  name: job-parallelism
spec:
  parallelism: 3 // 同時に3つのPodを起動して、ジョブを実行する。
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["curlchk",  "nginx"]
      restartPolicy: Never

1-4-4.動作確認

podのAGEを見ると同時実行されたことが分かる。

1-5.job自動終了および動作確認

1-5-1.Job作成

activeDeadlineSeconds：Jobによって生成されたPodが「アクティブ（Active）」であった合計時間を基準に、Podを終了させる。

※再試行回数の設定に関わらず終了させる。

※Podが起動中の状態でも終了させるが、terminationGracePeriodSecondsが未設定の場合、デフォルト値の30秒によって30秒間の猶予時間が与えられる。30秒を超過すると強制終了（kill）される。

※処理後、Jobは削除されない。

apiVersion: batch/v1
kind: Job
metadata:
  name: job-activedeadlineseconds
spec:
  backoffLimit: 3
  activeDeadlineSeconds: 30 //Pod作成を基準に、30秒後に終了するよう設定。
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: ["/bin/sh", "-c"]
        args:
        - sleep 80;
          curlchk nginx;  
      restartPolicy: Never

1-5-2.動作確認

①JobによるPod作成開始の30秒後にTerminating

②terminationGracePeriodSecondsのデフォルト値による30秒の猶予

③Podの強制終了（kill）

④Jobは削除されない

1-5-3.Job作成

ttlSecondsAfterFinished：Jobによって生成されたPodの終了後、リソースをクリーンアップ。

※Jobも削除される

apiVersion: batch/v1
kind: Job
metadata:
  name: job-ttlsecondsafterfinished
spec:
  backoffLimit: 3
  ttlSecondsAfterFinished: 30 //Jobによって起動されたPodの終了後、30秒後にリソースをクリーンアップ。
  template:
    spec:
      containers:
      - name: net-tools
        image: sysnet4admin/net-tools
        command: 
        - "/bin/sh"
        - "-c"
        - |
          echo "start"
          sleep 10
      restartPolicy: Never

1-5-4.動作確認

①Podの終了後、30秒後にリソースをクリーンアップ

②Jobも削除された

2.CronJob

2-1.CronJob作成および動作確認

2-1-1.Cronルール

2-1-2.CronJob作成

successfulJobsHistoryLimit：성공한 Job 오브젝트의 이력을 보관한다. 디폴트(3)

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cj-1m-hist3-curl 
spec:
  schedule: "*/1 * * * *"  //マスターノードのシステム時間を基準に起動する。
  jobTemplate:             # Template for job 
    spec:                  # same as before 
      template:
        spec:
          containers:
          - name: net-tools
            image: sysnet4admin/net-tools
            command: ["curlchk",  "nginx"]
          restartPolicy: Never

2-1-3.動作確認

①１分ごとにCronJob起動

②successfulJobsHistoryLimitによって、cj-1m-hist3-curl-29638867-8mk6w、fqt55削除

command/args

YOOANT — Sat, 9 May 2026 14:29:32 +0900

1.command/argsとは？

実務的な観点において、commandとargsはコンテナの起動時に「何を実行するか」を決定する最終指示書である。
イメージは一つだが、デプロイ環境や目的に応じて動作を変更する必要がある場合に使用する。

1-2.継続して動作させたい場合

1-2-1.まず、下記の検証用イメージとコードで動作を確認。

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: simple-wo-command
  name: simple-wo-command 
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools

検証用イメージの動作により、Podが異常終了している。

1-2-2.commandが定義された検証用コードで動作を確認。

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: simple-command
  name: simple-command 
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools
    command: ["/bin/sh", "-c", "sleep 3600"]

sleep 3600が適応され, Podが追加で生成されず、一つのみ動作している。

Podの内部に入り、commandの定義通りに動作しているかを確認。

1-3.ユーザーが任意のコマンドを実行させたい場合

1-3-1.command内に引数を含める場合

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: multiple-command-v1
  name: multiple-command-v1
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools
    command: ["/bin/sh", "-c", "echo run multiple-command-v1 && sleep 3600"]

1-3-2.command内に引数を含める場合2

※この場合、同時実行ではなく順次実行される。echo run multiple-command-v2 の実行後に sleep 3600

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: multiple-command-v2
  name: multiple-command-v2
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools
    command: ["/bin/sh", "-c", "echo run multiple-command-v2; sleep 3600"]

1-3-3. 実行プログラム・オプション・引数を分離して使用する場合

※この場合、1-3-2と同様に順次実行される

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: multiple-command-v3
  name: multiple-command-v3
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools
    command: 
    - "/bin/sh"
    - "-c"
    - |
      echo run multiple-command-v3
      sleep 3600

1-3-4.実行プログラムとオプションをまとめ、引数のみを分離する場合

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: multiple-command-w-args
  name: multiple-command-w-args
spec:
  containers:
  - image: sysnet4admin/net-tools
    name: net-tools
    command: ["/bin/sh","-c"]
    args: 
    - |
      echo run multiple-command-w-args
      echo add commentary 
      sleep 3600

Deployment、ReplicaSet

YOOANT — Fri, 8 May 2026 23:52:45 +0900

1.Deployment

例)Deployment.yaml

selectorとtemplateの関係性 selectorとtemplateは紐付けられる構造になっており、selectorがtemplateを（ラベルを介して）選択する仕組みになっている。

Ahahah I will not do it

Deploymentの中にはPodのコードが含まれていて、metadataやspecの部分はPodの定義とほぼ同じになっている。
ここから分かるのは、Deploymentが「Podを複数作るための枠組み」だということ。つまり、Podの構造をそのまま持ってきて、それをテンプレートとして使い回している。もう少し具体的に言うと、Deploymentはtemplateを使って複数のPodを作れるし、replicasの数を変えるだけで、Podを増やしたり減らしたり自由にコントロールできる仕組みになっている。

✅検証

セレクターのラベルとテンプレートのラベルが一致しない場合、デプロイメントは作成されない。

2.ReplicaSet

例)replicaset.yaml

ReplicaSet.yamlファイルの構造は、Deploymentと同一である。

Deploymentとkind部分だけが異なるのに、なぜあえてReplicaSetを使う必要があるのか？どちらか一方だけを使用すればよいのではないか？

なぜアプリのデプロイ時にReplicaSetではなくDeploymentを使用するのか？

　　→核心は「状態制御」と「履歴管理」にある。

2-1. 階層構造 (Hierarchy)

Deployment（戦略司令部）: どのイメージを使用し、どのような方式でデプロイするかを決定する。
ReplicaSet（現場監督）: 常に規定数のPodが稼働しているかを監視・維持する。
Pod（実務担当者）: 実際にコンテナが実行される最小単位。

2-2. アップデートのプロセス (Rolling Update)

イメージのバージョンを v1 から v2 に変更する場合のプロセスは以下の通りである。

新規RSの生成: Deploymentが v2 用のReplicaSetを新規作成する（既存の v1 用RSは保持される）。
入れ替え作業:
- v2 用RSのPod数を段階的に増加させる。
- v1 用RSのPod数を段階的に削減する。
- このプロセスを繰り返すことで、トラフィックを徐々に新バージョンへと移行させる。
結果: デプロイ完了後、v1 用RSはレプリカ数が「0」の状態で残る。これはロールバック（Rollback）を迅速に行うためであり、v2 に問題が発生した際、Deploymentが v1 用RSのレプリカ数を再設定するだけで旧バージョンへの復元が可能となる。

2-3. Deploymentを採用する理由

ReplicaSetのみを利用する場合、以下の作業を手動で行う必要がある。

新規ReplicaSetの作成。
既存ReplicaSetのスケールダウン。
デプロイ障害時の手動によるリソース調整。

Deploymentは、これらの煩雑かつリスクを伴うプロセスを自動化する抽象化エンジンとして機能するため、モダンなインフラ運用において不可欠なコンポーネントである。

それでは、ReplicaSetを実行してみたらどうだろうか。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: rs-nginx
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: po-nginx
  template:
    metadata:
      labels:
        app: po-nginx
    spec:
      containers:
      - image: nginx
        name: nginx

それでは、ReplicaSetを実行してみたらどうだろうか。

Pod状態

Podレベルでは差異がないことが確認できる。しかし、ここでの核心は「オブジェクトの目的」にある。ReplicaSetのみを単独で使用した場合、現在の状態を維持するというReplicaSetの限界が存在する。 Pod、ReplicaSet、Deploymentの有機的な関係を理解することで、Deploymentを十分に理解することができる。

Certified Kubernetes Application Developer(CKAD)取得

YOOANT — Mon, 4 May 2026 19:18:04 +0900

✅CKADとは?

Linux Foundationが認定するクバネティス（Kubernetes）関連の資格です。

実際の運用環境における実務能力を検証することに焦点が当てられています。

✅取得理由

CKA合格の流れを止めず、CKAD取得を決意しました。2年間クボネティス環境に携わってきましたが、主にCI/CDのための初期環境構築や基盤リソースの設定に注力してきました。運用体制上、開発チームがサービス維持管理や詳細設定を担当しているため、インフラ担当者として「実際のアプリケーションソースコードがどのようにデプロイされ、リソースが具体的にどう活用されているか」を深く掘り下げたいという渇望がありました。今回の機会に、インフラ提供者（Provider）の視点を超え、利用者（User）の視点からクボネティスのワークロードを完璧に理解したいと考えていました。

✅試験出題形式 (100%実技)

1.Containerビルドおよび保存

2.CronJob生成

3.DeploymentおよびService生成

4.Deploymentアップデートおよびロールバック

5.CanaryDeployment生成

6.Manifest生成

7.Probe設定

8.ResourceLimitRangeおよびQuota設定

9.Secret生成および設定

10.kube-apiserver権限付与

11.APPセキュリティー設定

12.NetworkPolicy設定

13.Ingress生成および設定