보통 pod 터미널에 접속할 때 kubectl exec로 접근해 왔다. 근데 운영팀에서 kubectl attach에 대해 물으셨고 나 또한 궁금증에 찾아보게 되었다.

attachexec의 차이점

attach exec
We can attach to the main process run by the container, which is not always bash. Which is the PID 1 It allows us to execute any process within the container
Attach to the one running (no choice) Run any command you want to execute

attachexec는 동일하게 pod에 접근할 수 있다. 하지만 가장 큰 차이점은 attach실행 중인 메인프로세스에만 접근할 수 있고 exec는 실행중인 아무 프로세스에나 접근이 가능하다는 것이다.

(참고로 컨테이너에서 메인프로세스는 spec.containers.command에 적혀진 가장 먼저 실행하는 프로세스이다. (PID 1))

그래서 attach는 새로운 프로세스를 생성하지 못하고 exec새로운 프로세스를 생성할 수 있다.

또한 attach로 접근하고 ctrl+c로 프로세스를 중지하는 경우 메인 프로세스를 죽여버리는 것이기 때문에 컨테이너가 restartPolicy 정책에 따라 재기동하게 된다

# attach는 메인프로세스에 바로 붙는 반면, exec는 date라는 명령어를 줌으로써 프로세스를 새로 실행하는 것을 볼 수 있다.
$ kubectl attach [pod명]
$ kubectl exec [pod명] -- date

stdin, tty 옵션 사용

참고 ) What is diff between kubectl exec and kubectl attach - DevOps - DevSecOps - SRE - DataOps - AIOps

위 글을 보고 attach를 사용하면 kubectl logs로 보는 것과 유사하게 stdout,stderr 로 출력하고 exec와 유사하게 stdin을 통해 입력받는다고 생각했다.

하지만 stdin을 통해 입력을 받으려면 execattach는 그냥 동일한 옵션 값을 사용하면 된다.

$ kubectl attach --help
	Attach to a process that is already running inside an existing container.

	Examples:
	# Switch to raw terminal mode; sends stdin to 'bash' in ruby-container from pod mypod
	# and sends stdout/stderr from 'bash' back to the client
	kubectl attach mypod -c ruby-container -i -t

	Options:
	-i, --stdin=false: Pass stdin to the container
	-t, --tty=false: Stdin is a TTY

help로 살펴 봤을 때, stdin 입력이 들어가면 터미널을 통해 stdout/stderr를 출력해 준다는 것이다

일단 stdin과 tty는 각각 -i, -t 라는 옵션을 주면 되는데 이는 기본 값이 false 이다.

Pod Docs를 참고하자!

- spec.containers.stdin: true
- spec.containers.tty: true

위 두 값을 true로 바꿔 준다면 터미널을 통해 stdin/stdout/stderr가 활성화된 것을 볼 수 있다!

Leave a comment