kubernetes와 helm chart 해보기

[hellices]

kubernetes 설치

k8s(kubernetes)란?
하드웨어 위에 컨테이너를 생성한다. 컨테이너는 한 개 이상의 앱으로 구성된다. 컨테이너를 관리하기 위한 api를 제공하여 아래와 같은 기능을 사용할 수 있도록 하는 것.

• 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다
• 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
  자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트할 수 있다.

kubernetes를 로컬환경에 설치하는 방법은 여러가지가 있으며 그 중 하나를 선택
minikube : kubernetes sig(special interest group)에서 제작한 가이드. docker 등 컨테이너 매니저가 필요하다.
docker desktop : docker desktop을 설치했다면 간단히 기능을 enable하는것으로 설치 가능.
k3d : rancher lab's에서 별도로 진행 중인 kubernetes lightweight wrapped version.

helm 설치

helm은 쿠버네티스 전용 패키지 매니저로 쿠버네티스에 소프트웨어를 설치하기 손쉬운 기능들을 제공한다.

install application

helm으로 postgresql install하기 -> #48

[hellices]

@shinhancard/dev_portal_team

[jobum97]

[Kubernetes] k3s를 이용해 single node 쿠버네티스 클러스터 구축하기

[jobum97]

https://minikube.sigs.k8s.io/docs/start/ 의 getStarted 따라하는 중


대쉬보드 생성까지 정상 진행

[jobum97]

Exiting due to MK_UNIMPLEMENTED: minikube service is not currently implemented with the builtin network on QEMU, try starting minikube with '--network=socket_vmnet'

에러 발생

[hellices]

https://minikube.sigs.k8s.io/docs/drivers/qemu/

[hellices]

지난 주 논의사항과 연계해서 알아야 할 것.
kubectl, helm 등으로 kubernetes에 명령을 보낼 때 필요한 토큰은 ~/kube/config 파일에 저장되어 관리된다.
이 토큰은 탈취가 가능하며 별도의 관리체계나 인증처리가 없으므로(vanilla kubernetes) 보안에 취약하다.

CSP(cloud service provider)는 토큰 만료 정책을 각각의 SSO 등과 통합하여 관리하고 있으며 CI/CD의 secret 등으로 처리할 수 있다.

이번 프로젝트는 github action -> eks 배포이며 eks와 통합하기 위한 토큰 발급은 회사 정책상 불가한 것으로 확인,
이를 해결하기 위해 flux를 도입하기로 결정함

[jobum97]

1st Try

https://minikube.sigs.k8s.io/docs/drivers/qemu/ 에서 알려준 대로
socket_vmnet 설치 후 옵션 값을 준 후 실행해 보고자 함

Problems detected in kubelet: Jul 26 04:06:30 minikube kubelet[41856]: W0726 04:06:30.192822 41856 reflector.go:533] object-"kube-system"/"coredns": failed to list *v1.ConfigMap: configmaps "coredns" is forbidden: User "system:node:minikube" cannot list resource "configmaps" in API group "" in the namespace "kube-system": no relationship found between node 'minikube' and this object Jul 26 04:06:30 minikube kubelet[41856]: E0726 04:06:30.192848 41856 reflector.go:148] object-"kube-system"/"coredns": Failed to watch *v1.ConfigMap: failed to list *v1.ConfigMap: configmaps "coredns" is forbidden: User "system:node:minikube" cannot list resource "configmaps" in API group "" in the namespace "kube-system": no relationship found between node 'minikube' and this object Jul 26 04:06:30 minikube kubelet[41856]: W0726 04:06:30.209161 41856 reflector.go:533] object-"kubernetes-dashboard"/"kube-root-ca.crt": failed to list *v1.ConfigMap: configmaps "kube-root-ca.crt" is forbidden: User "system:node:minikube" cannot list resource "configmaps" in API group "" in the namespace "kubernetes-dashboard": no relationship found between node 'minikube' and this object Jul 26 04:06:30 minikube kubelet[41856]: E0726 04:06:30.209196 41856 reflector.go:148] object-"kubernetes-dashboard"/"kube-root-ca.crt": Failed to watch *v1.ConfigMap: failed to list *v1.ConfigMap: configmaps "kube-root-ca.crt" is forbidden: User "system:node:minikube" cannot list resource "configmaps" in API group "" in the namespace "kubernetes-dashboard": no relationship found between node 'minikube' and this object

추가적인 다른 에러를 만남

[hellices]

kube-root-ca.crt -> 파일 권한문제같기도?

[jobum97]

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state
이 문제인 것 같음

Pods in RunContainerError, CrashLoopBackOff or Error state
Right after kubeadm init there should not be any pods in these states.

If there are pods in one of these states right after kubeadm init, please open an issue in the kubeadm repo. coredns (or kube-dns) should be in the Pending state until you have deployed the network add-on.
If you see Pods in the RunContainerError, CrashLoopBackOff or Error state after deploying the network add-on and nothing happens to coredns (or kube-dns), it's very likely that the Pod Network add-on that you installed is somehow broken. You might have to grant it more RBAC privileges or use a newer version. Please file an issue in the Pod Network providers' issue tracker and get the issue triaged there.