Chad M. Crowell

개요

killercoda의 세번째 실습 문제들.
여기는 문제라기보다 그냥 실습이라, 쭉 따라하면 된다.
너무 불필요하게 확인하는 부분, 그냥 혼자 하고 넘어가는 게 낫다 싶으면 제거했다.

하다보니 문제스럽지도 않고.. 그냥 실습이라 나 혼자 정리하면서 진행한다.

Install a Database Operator

Install Operator

# set your username
export GITHUB_USERNAME="<your-github-username>"
# clone the repo
git clone --depth 1 "https://github.com/${GITHUB_USERNAME}/postgres-operator-examples.git"
# change directory 
cd postgres-operator-examples

https://github.com/CrunchyData/postgres-operator-examples/fork 포크한 후, 아래 명령을 통해 환경에 저장하라.
굳이 포크까지.. 싶어서 그냥 받아서 진행해본다.

kubectl apply -k kustomize/install/namespace
kubectl apply --server-side -k kustomize/install/default

이후 오퍼레이터를 아래의 방법으로 설치할 수 있다.
kustomize를 사용하는 방식이다.
쿠스토마이즈는 처음이라 도전해본다.

처음에는 네임스페이스를 만든다.

alias로 kubectl을 쓰니 에러가 났다.
kustomize가 자동완성도 안 되던데, 관련한 이슈로 보인다.
기본적으로 kubectl에 완벽히 결합된 방식이 아니라 조심해야 할 듯.

Create Database CRD

k apply -k kustomize/postgres

오퍼레이터가 설치됐다면 포스트그레 클러스터를 만들자.
hippopostgres-operator에 생길 것이다.

k -n postgres-operator get postgresclusters
k -n postgres-operator describe postgresclusters hippo

이렇게 만들면 유저 계정이 만들어진다.

k -n postgres-operator get secrets

해당 계정 정보는 시크릿 hippo-pguser-rhino에 저장된다.

export PG_CLUSTER_PRIMARY_POD=$(kubectl get pod -n postgres-operator -o name -l postgres-operator.crunchydata.com/cluster=hippo,postgres-operator.crunchydata.com/role=master)

kubectl -n postgres-operator port-forward "${PG_CLUSTER_PRIMARY_POD}" 5432:5432

탭을 새로 열고 포트포워딩을 진행한다.

export PG_CLUSTER_USER_SECRET_NAME=hippo-pguser-rhino
export PGPASSWORD=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.password | base64decode}}')
export PGUSER=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.user | base64decode}}')
export PGDATABASE=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.dbname | base64decode}}')
psql -h localhost

포그 클러스터에 연결하라.
계정정보를 환경변수로 저장하여 진행한다.

CREATE SCHEMA rhino AUTHORIZATION rhino;

위와 같이 스키마를 만든다.
포그에서는 스키마를 만드는 행위는 하나의 데이터베이스 오브젝트를 구성한다.
이를 통해 여러 유저가 같은 데이터베이스를 잘 관리할 수 있도록 돕는다.

Scale the Database

PostgresCluster CRD를 수정하여 스케일링을 진행할 수 있다.
파드의 수가 조절되는데 이 과정은 자동적으로 일어난다.

k -n postgres-operator get postgresclusters hippo -o yaml


PostgresCluster yaml 파일을 에서 spec 부분을 확인한다.
레플리카가 1로 설정됐다.

수정하여 레플리카를 3으로 늘리자.
새로운 두 파드가 생길 것이다.

kubectl logs -n postgres-operator -l postgres-operator.crunchydata.com/control-plane=postgres-operator

오퍼레이터는 레플리카들이 동기화되는 것을 보장한다.
로그를 통해 확인할 수 있다.

이부분을 말하는 듯.

Simulate a DB Failure

파드 실패를 통해 회복 매커니즘을 테스트해보자.

k -n postgres-operator get pods --show-labels | grep role


파드 간 관계를 확인할 수 있다.
이중 한 파드를 지우고, 상태를 확인한다.

마스터 파드를 지웠는데, 같은 이름으로 다시 만들어졌다.
스테이트풀셋으로 관리돼서 그런 듯.

이벤트로 해당 사항이 남는다고 했는데, 내 이벤트에는 보이지 않는다.

원래는 이런 사항이 보여야 한다는데..
근데 statefulset을 보는 게 맞지 않나..?

k -n postgres-operator logs -l postgres-operator.crunchydata.com/control-plane=postgres-operator

로그로도 뜨지 않는다.

삭제를 했는데, 삭제한 내역이 스테이트풀셋에도 없다.
그냥 시작했다는 말만 반복되는데, 사실 이건 맞는 것 같다.
어쩌면 수정이 된 것일 수도 있겠다.

psql -h localhost
SELECT pg_is_in_recovery();


아무튼 분명히 제대로 동기화와 복원은 일어났다.

kubectl exec -it -n postgres-operator <replica-pod-name> -- psql -U postgres -d postgres
SELECT pg_last_wal_replay_lsn();


이건 복제 상태를 보여준다고 한다.
뭔가 제대로 되는 건 없는 것 같다.

Debug a Go App in Kubernetes

Try to Access The Go App

서비스와 디플이 있는데, 서비스 FQDN에 curl을 써본다.

솔루션에 나온 대로 해봤지만.. 리졸빙부터가 안 된다.
그냥 따라하기인 것 같아서 실망했다가 급 재밌어지는 중..
아마 원래 의도는.. hosts 파일에 해당 도메인을 미리 넣어두는 것 아니었을까?

일단 그냥 ip로 넣으면 연결이 끊긴다.

포트포워딩시켜봤는데 로컬호스트 도메인으로는 연결을 진행할 수 없다.

아.. 이제보니 안속에 그냥 문제가 있다.

Debug The App

아! 이걸 해결하는 게 애초에 문제였다!!ㅋㅋㅋ
이게 컨테이너 내부 프로세스고, 애초에 해당 이미지 이름부터가 fail 머시기다;

???
너가 이미지로 만든 걸 지금 내가 고쳐서 새로 빌드해서 올리라고?
씁..

도메인 문제나 보자면, 생각해보니 아까는 내가 그냥 클러스터 밖에서 시도를 해서 안 보이는 거였다.
netshoot하니까 바로 리졸빙됐다.

List API Resources

List All Cluster Resources

모든 api 리소스를 resources.csv에 저장하자.

... 언제부터 탭이 csv 구분자였냐?
진짜 개빡치게 하네

수정..

솔직히 여기 몇 개는 해도 의미가 없다.
뻔한 것들 뿐이라..
차라리 이전에 Sachin H R이 선녀였다.
그래서 문제들을 보고나서 할 만한 것들만 따로 해보려고 한다.

참고