블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

아두이노 무선 통신 모듈

프로그래밍/아두이노 | 2018.09.21 00:41 | Posted by 조대협

아두이노 무선 통신 모듈


아두이노를 어느정도 테스트해보니, 서버에 붙여서 몬가를 해봐야겠다는 생각에 와이파이 지원 모듈을 찾다보니 꽤나 복잡해서 정리를 해본다.

아두이노의 무선 통신 모듈은 원래 아두이노 와이파이 실드라는 파츠로, 아두이노 우노 위에 붙여서 사용하는 형태 였는데, 사용방법은 편리하나 가격이 비싼 편이고, 아두이노 우노 시리즈에만 호환되는 단점을 가지고 있다.


<그림 아두이노 와이파이 실드 정품 >


그러다가 WIFI가 대중화된것이 ESP8266 이라는 칩셋인데, 아주 저렴한 가격에 (인터넷에서 2000원 수준) 이를 통해서 많이 대중화가 되었다.

<그림 AI Cloud사의 ESP8266 모듈>

가격은 저렴하지만 3.3V 전류를 사용하기 때문에, 별도의 저항등의 배선 설정이 필요하고, 특히 시리얼 라인 속도도 조정해야 하고, 펌웨어를 업그레이드해야 하는등 번거로운 작업이 필요하다. (특히 나같은 맥북 사용자에게는 쥐약인..)

ESP8266 모듈의 호한 모듈로는 AI Thinker사의 제품이 많은데 ESP-OO 식의 이름을 가지고 있는데, 인터넷 상에서 파는 제품은 ESP-12 시리즈가 많다. ESP-12등은 ESP8266 모듈 호환이라고 생각하면 된다. 


그래서 대체품을 찾은것이 nodemcu 라는 제품인데

<그림 ESP8266 기반의 nodemcu>


ESP 8266 모듈을 기판에 붙여 놓고 입출력 IO핀을 제공하면서도, USB 단자가 있어서 펌웨어 업그레이드를 상대적으로 편하게 할 수 있으며, Lua 스크립트로도 코딩이 가능하다.

즉 아두이노가 없이도 단독적으로 기능 수행이 가능하다는 이야기인데, 크기가 작고 와이파이 기능이 탑재되어 있어서 IOT 기기류로 많이 활용되는 듯하다. 특히 Lua 의 경우 HTTP나 MQTT와 같은 IOT 프로토콜을 손쉽게 호출할 수 있는 라이브러리가 있어서 어떤면에서는 아두이노보다 통신 프로그램에는 유리하지 않은가 싶다. 


ESP8266이 많이 사용되기는 했지만, 다음 버전으로 ESP32 라는 프로세서가 등장하는데, WIFI뿐 아니라 블루투스 통신을 함께 지원한다.

아무래도 후속 기중인 만큼 더 많은 GPIO 포트와, 더 빠른 WIFI통신을 지원하기는 하지만, 가격이 약간 더 비싸다는 단점이 있다. (6$~12$선)


<그림 ESP 32S 칩을 내장한 nodemcu 모듈 >


그외에, 아두이노 호환보드중에는 WIFI 기능을 내장한 보드들이 꽤 많다. 대표적인 보드로는 Wemos 사의 제품이 있는데, ESP8266 을 메인 CPU로 한후에, 우노에 맞는 사이즈와 핀 배열과 기능을 제공하면서 기본적으로 ESP8266 기반의 와이파이 통신을 지원한다. 


또는 아두이노 WIFI 실드 제품을 사용하는 것도 방법이 된다.






'프로그래밍 > 아두이노' 카테고리의 다른 글

아두이노 무선 통신 모듈  (0) 2018.09.21
아두이노 기울기 센서와 소음 센서  (0) 2018.09.18
아두이노 조도 센서  (0) 2018.09.16
Hello 아두이노  (0) 2018.09.16

아두이노 기울기 센서와 소음 센서


아두이노 기울기와 소음센서를 간단하게 테스트 해봤다.


소음 센서

소음 센서는 소리가 나면 그 값을 아닐로그값으로 바꿔서 준다. +5V와 GND에 연결하고, 데이타값은 아날로그 포트에 연결해서 받는다. 



아래는 간단한 코드

#include <Arduino.h>


void setup() {

Serial.begin(115200);

}


void loop() {

int sound = 1024-analogRead(A0);

Serial.println(sound);

delay(20);

}


--- 9월 18일 수정 ---

위의 센서는 아날로그가 아니라 디지털임.

소리가 날때, 작은 값이 나오고, 소리가 안날때 1024값이 나오는데, 이건 중간에 가변 저항을 돌려보면 반대로 만들 수 있음 (포텐셔미터라고들 부르는데)

"디지탈 센서의 출력을 아날로그로 읽었으니 0과 1024 혹은 그에 가까운 값이 나오는것이 맞고, 그 사이값 30, 600, 900 이런 값들은 디지탈 출력이 빠른 시간에 ON/OFF 되는 것이 마치 PWM 출력처럼 읽혀서 나오는 값입니다." 커뮤니티에서 임성국님이 정리해주신 내용


기울기 센서

각도등은 받을 수 없고, 디지털 센서로 기울어진 여부만 측정한다.



마찬가지로 5V와 GND 단자에 연결한 후에, 데이타 단자를 디지털 단자에 연결하고, 이 단자를 입력값으로 설정하여 기울어진 여부를 입력 받는다.


#include <Arduino.h>


void setup() {

pinMode(13,INPUT);

Serial.begin(115200);


}


void loop() {

boolean tilt = digitalRead(13);

delay(300);

Serial.print(tilt);


}





'프로그래밍 > 아두이노' 카테고리의 다른 글

아두이노 무선 통신 모듈  (0) 2018.09.21
아두이노 기울기 센서와 소음 센서  (0) 2018.09.18
아두이노 조도 센서  (0) 2018.09.16
Hello 아두이노  (0) 2018.09.16

아두이노 조도 센서

프로그래밍/아두이노 | 2018.09.16 00:59 | Posted by 조대협

가지고 있는 센서가 몇개 안되서, 그중에 간단한 조도 센서를 테스트해봤다.

5V와 아날로그 INPUT 단자를 이용하면, 쉽게 값을 받을 수 있다.




코드는

#include <Arduino.h>


void setup() {

Serial.begin(115200);

}


void loop() {

int light = analogRead(A0);

Serial.println(light);

delay(500);

}


특별한 부분은 없고, analogRead 함수를 써서, 읽고자 하는 아날로그 포트를 지정해주면 된다.

노트북 빼고 연결 가능하게, 외부 전원 설치방법과, WIFI 연결, HTTP REST API 호출, LCD 출력등을 좀 더 테스트 해봐야겠다.

SERVO 모터를 이용해서, 조정하는 것도 해보고. 이걸 하면 로보트팔을 만들 수 있지 않을까?



'프로그래밍 > 아두이노' 카테고리의 다른 글

아두이노 무선 통신 모듈  (0) 2018.09.21
아두이노 기울기 센서와 소음 센서  (0) 2018.09.18
아두이노 조도 센서  (0) 2018.09.16
Hello 아두이노  (0) 2018.09.16

Hello 아두이노

프로그래밍/아두이노 | 2018.09.16 00:39 | Posted by 조대협


잠깐 아두이노를 만져보고 단상 노트


우연한 기회에 아두이노를 보게 되서, 예전에 딸 학습용으로 사놨던 아두이노 키트를 꺼내서 이리저리 만져보았다.

요즘 아이들이 아두이노로 메이커를 많이 한다고 해서, 난이도가 높지 않을것이라고는 예상 했지만, 직접 해보니, 상당히 심플하다.

개발 환경 설정에서 부터, 코드를 올리는 과정까지 IDE에서 손쉽게 접근이 가능하고, 브래드보드 덕분인지, 회로 구현도 편하고, 부품 수급도 편리하다.

더군다나, 시장에 많이 풀린 덕분인지 컨텐츠도 무궁무진해서, 손쉽게 접근이 가능하다.


13개의 핀을 IN/OUT으로 설정하고 단순하게 신호를 보내거나 받아서 처리하는 구조인데...

저항이나 콘덴서와 같은 전자 부품을 어떻게 다룰지 약간 걱정은 되지만, 아이들도 한다고 하니, 크게 문제는 없을듯 하다.


대략 감도 잡고 환경도 구축을 했는데, 무엇을 해볼까 고민중

아무래도 백앤드 전문이니, WIFI 를 달아서, 센서로 값들을 수집하는 IOT 시나리오를 구축하는 것도 괜찮을거 같고

ML API나 쳇봇 API를 이용해서, 간단한 로봇을 만들거나, 아니면 라즈베리 파이로 넘어가서 텐서플로우 모델을 내려보는것도 괜찮을거 같기는 한데, 어떤 시나리오를 할지 역시 아이디어가 문제다.





아래는 오늘 개발 환경 구축에 참고한 영상인데, 아무래도 이클립스와 같은 툴에 익어 있다 보니, 아두이노 정식 IDE보다는 이클립스가 날거 같아서 설치했는데, 역시 요즘은 글보다는 영상이 대세인가 보다. 이해도 빠르고.. 따라하기도 편리하다. 블로그 대신 이제 영상으로 넘어가야 하나??



'프로그래밍 > 아두이노' 카테고리의 다른 글

아두이노 무선 통신 모듈  (0) 2018.09.21
아두이노 기울기 센서와 소음 센서  (0) 2018.09.18
아두이노 조도 센서  (0) 2018.09.16
Hello 아두이노  (0) 2018.09.16

쿠버네티스 #19

보안 4/4 - Pod Security Policy

조대협 (http://bcho.tistory.com)



SecurityContext가 컨테이너나 Pod의 보안 기능을 정의 하는 것이라면, Pod Security Policy (이하 PSP)는 보안 기능에 대한 정책을 정의 하는 것이다.

예를 들어, 정책으로 Pod를 생성할때는 반드시 root 사용자를 사용하지 못하도록 강제한다던지, Privileged 모드를 사용못하도록 강제할 수 있다. 현재는 (2018년9월1일) 베타 상태이기 때문에 다소의 기능 변경이 있을 수 있음을 염두하고 사용하도록 하자.

개념

개념이 복잡하기 때문에 먼저 기본적인 개념을 이해한 후에, 각 상세를 살펴보도록 하자.

먼저 아래 그림을 보자 PSP는 생성후에, 사용자에게 지정이 된다.

그리고 Pod를 생성할때, Pod의 보안 요건을 SecurityContext를 이용해서 Pod 설정에 정의한다.

Pod를 생성하려고 할때, 생성자(사용자)의 PSP를 레퍼런스 하는데, Pod의 보안 요건이 사용자에게 정의되어 있는 PSP 요건을 만족하면, Pod가 생성된다.



반대로, Pod를 생성할때, Pod의 보안 요건 (SecurityContext)가 Pod를 생성하고자하는 사용자의 PSP요건을 만족하지 않으면, Pod 생성이 거부된다. 아래 그림은 사용자의 PSP에서 Privileged 모드를 사용할 수 없도록 설정하였으나, Pod를 생성할때 Privileged 모드를 Pod 가 사용할 수 있도록 설정하였기 때문에, Pod를 생성에 실패하는 흐름이다.




Pod Security Policy

Pod Security Policy는 Security Context와 달리 클러스터 리소스 (Cluster Resource)이다.

즉 적용하는 순간 클러스터 전체에 적용이 된다는 이야기이다.


정책 종류

Pod Security Policy를 통해서 통제할 수 있는 정책은 다음과 같다.

(출처 https://kubernetes.io/docs/concepts/policy/pod-security-policy/) 자세한 내용은 원본 출처를 참고하기 바란다.


Control Aspect

Field Names

Running of privileged containers

privileged

Usage of host namespaces

hostPID, hostIPC

Usage of host networking and ports

hostNetwork, hostPorts

Usage of volume types

volumes

Usage of the host filesystem

allowedHostPaths

White list of Flexvolume drivers

allowedFlexVolumes

Allocating an FSGroup that owns the pod’s volumes

fsGroup

Requiring the use of a read only root file system

readOnlyRootFilesystem

The user and group IDs of the container

runAsUser, supplementalGroups

Restricting escalation to root privileges

allowPrivilegeEscalation, defaultAllowPrivilegeEscalation

Linux capabilities

defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities

The SELinux context of the container

seLinux

The AppArmor profile used by containers

annotations

The seccomp profile used by containers

annotations

The sysctl profile used by containers

annotations



포맷

PSP의 포맷을 이해하기 위해서 아래 예제를 보자

apiVersion: extensions/v1beta1

kind: PodSecurityPolicy

metadata:

 name: nonroot-psp

spec:

 seLinux:

   rule: RunAsAny

 supplementalGroups:

   rule: RunAsAny

 runAsUser:

   rule: MustRunAsNonRoot

 fsGroup:

   rule: RunAsAny

 volumes:

 - '*'


nonroot-psp 라는 이름으로 PSP를 정의하였고, seLinux,supplementalGroup,fsGroup과 volumes(디스크)에 대한 권한은 모두 허용하였다. runAsUser에 rule (규칙)을 MustRunAsNonRoot로 지정해서, 이 정책을 적용 받은 사용자는 Pod를 생성할때 Pod가 반드시 root 사용자가 아닌 다른 사용자를 지정하도록 정의했다.

PSP 사용자 적용

PSP 를 정의하고 실행한다고 해도, 실제로 적용되지 않는다. PSP를 적용하기 위해서는 생성한 PSP를 RBAC을 이용하여 ClusterRole을 만들고, 이 ClusterRole을 사용자에게 부여해야 실제로 정책이 적용되기 시작한다. 사용자에게 PSP를 적용하는 부분은 뒤의 예제에서 살펴보자

이때 주의할점은 사용자의 정의인데, 쉽게 생각하면 사용자를 사람으로만 생각할 수 있는데, 쿠버네티스의 사용자는 사람이 될 수 도 있지만 서비스 어카운트 (Service account)가 될 수 도 있다.

쿠버네티스에서 Pod를 생성하는 주체는 사용자가 kubectl 등으로 Pod를 직접생성할 경우, 사람이 사용자가 되지만, 대부분의 경우 Pod의 생성과 관리는 Deployment나 ReplicaSet과 같은 컨트롤러를 이용하기 때문에, 이 경우에는 컨트롤러들이 사용하는 서비스 어카운트가 사용자가 되는 경우가 많다.

그래서, PSP를 적용하는 대상은 일반 사용자가 될 수 도 있지만 서비스 어카운트에 PSP를 적용해야 하는 경우가 많다는 것을 반드시 기억해야 한다.

PSP 활성화

PSP는 쿠버네티스 클러스터에 디폴트로는 비활성화 되어 있다. PSP 기능을 사용하기 위해서는 이를 활성화 해야 하는데, PSP는 admission controller에 의해서 컨트롤 된다.

구글 클라우드

구글 클라우드에서 PSP를 활성화 하는 방법은 아래와 같이 gcloud 명령을 이용하면 된다.


%gcloud beta container clusters update {쿠버네티스 클러스터 이름} --enable-pod-security-policy --zone={클러스터가 생성된 구글 클라우드 존}


만약에 활성화된 PSP 기능을 비활성화 하고 싶으면 아래와 같이 gcloud 에서 --no-enable-pod-security-policy  옵션을 사용하면 된다.


gcloud beta container clusters update {쿠버네티스 클러스터 이름}  --no-enable-pod-security-policy --zone={클러스터가 생성된 구글 클라우드 존}

Minikube

minikube start --extra-config=apiserver.GenericServerRunOptions.AdmissionControl=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds,PodSecurityPolicy


주의할점은 PSP 기능이 활성화된후에, PSP가 적용되지 않은 사용자(사람과, 서비스어카운트 모두)의 경우에는 Pod를 생성할 수 없기 때문에, 기존에 잘 생성되던 Pod가 갑자기 생성되지 않는 경우가 많기 때문에, 반드시 기능을 활성화하기 전에 반드시, 사용자마다 적절한 PSP를 생성해서 적용하기 바란다. (PSP기능을 활성화하지 않더라도 기본적으로 PSP 정의및, PSP를 사용자에게 적용하는 것은 가능하다.)

예제

개념에 대한 이해가 끝났으면 이제 실제 예제를 통해서 어떻게 PSP를 생성 및 적용하는지를 알아보도록 하자. 예제는 다음 순서로 진행하도록 한다.

  1. PSP 정의 : Root 권한을 사용이 불가능한 PSP를 생성한다.

  2. 서비스 어카운트 생성 : PSP를 생성할 서비스 어카운트를 생성한다. Pod를 바로 생성하는 것이 아니라 Deployment를 통해서 생성할것이기 때문에 Deployment에서 이 서비스 어카운트를 사용할것이다.

  3. ClusterRole 생성 : 다음 1에서 만든 PSP를 2에서 만든 서비스 어카운트에 적용하기 위해서, PSP를 가지고 있는 ClusterRole을 생성한다.

  4. ClusterRoleBinding을 이용하여 서비스 어카운트에 PSP 적용 : 3에서 만든 ClusterRole을 2에서 만든 서비스 어카운트에 적용한다.

  5. Admission controller 활성화 : PSP를 사용하기 위해서 Admission controller를 활성화 한다.

  6. Pod 정의 및 생성 : 2에서 만든 서비스 어카운트를 이용하여 Deployment 를 정의한다.

  7. 테스트 : 테스트를 위해서, root user를 사용하는 deployment와, root user를 사용하지 않는 deployment 두개를 각각 생성해서 psp 가 제대로 적용되는지를 확인한다.

PSP 정의

PSP를 정의해보자. 아래와 같이 nonroot-psp.yaml 을 작성한다. 이 PSP는 runAsUser에서 MustRunAsNotRoot 규칙을 추가해서, Root 권한으로 컨테이너가 돌지 않도록 하는 정책이다.


# nonroot-psp.yaml

apiVersion: extensions/v1beta1

kind: PodSecurityPolicy

metadata:

 name: nonroot-psp

spec:

 seLinux:

   rule: RunAsAny

 supplementalGroups:

   rule: RunAsAny

 runAsUser:

   rule: MustRunAsNonRoot

 fsGroup:

   rule: RunAsAny

 volumes:

 - '*'


파일을 nonroot-psp.yaml 파일로 저장한후에,

%kubectl create -f nonroot-psp.yaml

명령어를 이용하여 PSP를 생성한후에,

%kubectl get psp

명령을 이용하여, PSP가 생성된것을 확인하자




서비스 어카운트 생성

서비스 어카운트 생성을 위해서 아래 yaml 파일을 작성하고, 서비스 어카운트를 생성하여 확인하자


#nonroot-sa.yaml

apiVersion: v1

kind: ServiceAccount

metadata:

 name: nonroot-sa



ClusterRole 생성 및 적용

서비스 어카운트를 생성하였으면, 앞에 만든 PSP nonroot-psp 를 사용하는 ClusterRole nonroot-clusterrole을 생성하고, 이 롤을 nonroot-clusterrole-bindings를 이용하여, 앞서 만든 서비스 어카운트 nonroot-sa 에 연결한다.


아래와 같이 ClusterRole을 생성하는데, resouces 타입을 podsecuritypolicies 로 정의하고, 리소스 이름은 앞에서 생성한 PSP인 nonroot-psp로 지정한다. 그리고, 이 psp를 사용하기 위해서 verb는 “use”로 지정한다

#nonroot-clusterbinding.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

 name: nonroot-clusterrole

rules:

- apiGroups:

 - policy

 resources:

 - podsecuritypolicies

 resourceNames:

 - nonroot-psp

 verbs:

 - use


%kubectl create -f nonroot-clusterrole.yaml

명령어를 이용하여 위의 ClusterRole을 생성한후에, 이 ClusterRole을 서비스 어카운트 nonroot-sa 에 적용하자.

아래와 같이 nonroot-clusterrolebinding.yaml 를 생성한후,


#nonroot-clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

 name: nonroot-clusterrole-bindings

subjects:

- kind: ServiceAccount

 name: sa-nonroot

 namespace: default

roleRef:

 apiGroup: rbac.authorization.k8s.io

 kind: ClusterRole

 name: nonroot-clusterrole


%kubectl create -f nonroot-clusterrolebinding.yaml

명령어를 이용하여 ClusterRole nonroot-clusterrole을 서비스 어카운트 sa-nonroot에 적용한다.

도커 컨테이너 생성

이제 PSP가 생성되었고, 이 PSP를 사용하는 서비스 어카운트 nonroot-sa 가 완성되었으면, 이를 실제로 배포에 적용해보자. 배포에 앞서서 컨테이너 이미지를 만든다.

아래는 Docker 파일인데, 앞의 보안 컨텍스트 설명때 사용한 컨테이너와 동일하다.


#Dockerfile

FROM node:carbon

EXPOSE 8080

RUN groupadd -r -g 2001 appuser && useradd -r -u 1001 -g appuser appuser

RUN mkdir /home/appuser && chown appuser /home/appuser

USER appuser

WORKDIR /home/appuser

COPY --chown=appuser:appuser server.js .

CMD node server.js > /home/appuser/log.out

생성된 도커이미지를 gcr.io/terrycho-sandbox/nonroot-containe:v1 이름으로 docker push 명령을 이용해서  컨테이너 레지스트리에 등록한다.

PSP 기능 활성화

이미지까지 준비가 되었으면, 이제 Pod를 생성할 모든 준비가 되었는데, PSP를 사용하려면, 쿠버네티스 클러스터에서 PSP 기능을 활성화 해야 한다.

다음 명령어를 이용해서 PSP를 활성화한다.

%gcloud beta container clusters update {쿠버네티스 클러스터 이름} --enable-pod-security-policy --zone={클러스터가 생성된 구글 클라우드 존}


아래 그림과 같이 PSP 기능이 활성화 되는 것을 확인한다.


Deployment 생성

기능 활성화가 끝났으면, 이제 Pod를 deploy해보자.

아래는 nonroot-deploy.yaml 파일이다.


#nonroot-deploy.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

 name: nonroot-deploy

spec:

 replicas: 3

 selector:

   matchLabels:

     app: nonroot

 template:

   metadata:

     name: nonroot-pod

     labels:

       app: nonroot

   spec:

     serviceAccountName: nonroot-sa

     securityContext:

       runAsUser: 1001

       fsGroup: 2001

     containers:

     - name: nonroot

       image: gcr.io/terrycho-sandbox/security-context:v1

       imagePullPolicy: Always

       ports:

       - containerPort: 8080


우리가 nonroot-psp를 사용하기 위해서, 이 psp가 정의된 서비스 어카운트 nonroot-sa를 사용하도록 하였다. 그래고 nonroot-psp에 정의한데로, 컨테이너가 root 권한으로 돌지 않도록 securityContext에 사용자 ID를 1001번으로 지정하였다.

%kubectl create -f nonroot-deploy.yaml

을 실행한후,

%kubectl get deploy 명령어를 실행해보면 아래와 같이 3개의 Pod가 생성된것을 확인할 수 있다.


보안 정책에 위배되는 Deployment 생성

이번에는 PSP 위반으로, Pod 가 생성되지 않는 테스트를 해보자.

아래와 같이 root-deploy.yaml 이라는 이름으로, Deployment 스크립트를 작성하자.


#root-deploy.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

 name: root-deploy

spec:

 replicas: 3

 selector:

   matchLabels:

     app: root

 template:

   metadata:

     name: root-pod

     labels:

       app: root

   spec:

     serviceAccountName: nonroot-sa

     containers:

     - name: root

       image: gcr.io/terrycho-sandbox/nonroot-containe:v1

       imagePullPolicy: Always

       ports:

       - containerPort: 8080


이 스크립트는 앞에서 작성한 nonroot-deploy.yaml 과 거의 유사하지만 Security Context에서 사용자 ID를 지정하는 부분이 없기 때문에, 디폴트로 root로 컨테이너가 기동된다. 그래서 PSP에 위반되게된다.


%kubectl create -f root-deploy.yaml

을 실행하면 결과가 아래와 같다.



맨 아래 root-deploy-7895f57f4를 보면, Current 가 0으로 Pod가 하나도 기동되지 않았음을 확인할 수 있다.

원인을 파악하기 위해서 Pod를 만드는 ReplicaSet을 찾아보자

%kubectl get rs

명령을 아래와 같이 ReplicaSet 리스트를 얻을 수 있다.

%kubectl describe rs root-deploy-7895f57f4

명령을 실행해서 ReplicaSet의 디테일과 로그를 확인해보면 다음과 같다.



그림과 같이 Pod 생성이 정책 위반으로 인해서 실패한것을 확인할 수 있다.