쿠버네티스 관련된 기술들이 워낙 많다보니 뭘 어디서부터 손대야할지 모를때도 있고 하다보면 어디에 서 있는지도 모를때가 있다. 더 나가 쿠버네티스를 시작하려고할때에 이게 어디에 있는건지를 알고 싶을때가 종종 있는데, 웹 서핑을 하다가 주운걸 기록해본다. 딱봐도 채용공고에 내용인데, 굵직하게 정리가 되어서 긁어왔다. 여기서 한가지 추가해야 한다면 IaC 부분인데, 요새는 쿠버네티스에 뭔가를 설치할때는 다음과 같은 걸 많이 사용한다. ArgoCD 도 있지만 이것은 사실 애플리케이션 배포에 쓰인다고 보면 된다. 요새 하도 공부를 하지 않아서 잃어버리는 기억도 많고 이제는 쓰지 않는 기술들도 많은데, 슬슬 다시 공부를해야 […]
Kubernetes
Kubernetes API 서버 인증서에 도메인 추가하기
Kubernetes API 서버는 http 를 통해서 쿠버네티스에 대한 연산을 제공해 준다. kubectl 명령어로 실행되는 것들은 모두 API 서버를 거쳐서 이루어진다. 하지만 API 서버는 인증서를 기반으로 통신이 이루어지는데, 이 인증서에 기재된 도메인이나 IP가 아니면 통신이 이루어지지 않는다.
|
1 |
kubectl unable to connect to server: x509: certificate signed by unknown authority |
API 서버의 인증서는 SAN 인증서여야 한다. 도메인 리스트를 가지고 있는 SAN 인증서. 현재 API 서버의 인증서 상태는 다음과 같다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
$ openssl x509 -text -in /etc/kubernetes/pki/apiserver.crt -noout X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Authority Key Identifier: keyid:98:B6:19:7B:C4:FF:03:49:74:7D:F3:F1:7E:31:67:91:D9:2E:B5:EA X509v3 Subject Alternative Name: DNS:haproxy2.systemv.local, DNS:kmaster, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:ol85.systemv.local, DNS:rhel8.systemv.local, IP Address:10.96.0.1, IP Address:192.168.96.23, IP Address:192.168.96.30, IP Address:192.168.96.7 Signature Algorithm: sha256WithRSAEncryption |
위 apiserver.crt 파일 상태를 보면 SAN 에 이미 도메인과 IP 들이 들어가 있다. 내용을 보면 haproxy2.systemv.local 도메인, 192.168.96.7 IP 가 들어가 있는데 이 […]
Kubernetes
Kubernetes 의 Role Based Access Control(RBAC)
쿠버네티스는 RBAC 기반으로 허가권(Permission) 을 조정하도록 설계 되었다. 그런데, 쿠버네티스는 다음과 같이 네가지의 Role 관련 리소스를 가지고 있다. 그 차이는 다음과 같다. ClusterRole – 전체 클러스터에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission) ClusterRoleBinding – 특정 계정(Account) 에 ClusterRole 을 바인딩 Role – 특정 네임스페이스에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission) RoleBinding – 특정 계정(Account) 에 Role 을 바인딩 RBAC 을 적용하기 위해서는 계정이 필요하다. 이 계정은 쿠버네티스의 사용자를 말하는것이 아닌 쿠버네티스에서 운영되는 자원에 대한 계정을 말한다. 예를들어 ingress-nginx 라는 계정을 […]
Kubernetes
쿠버네티스 curl 사용하기
쿠버네티스에서 클러스터내에서 Pod 에 데이터가 잘 나오는지를 확인하는 방법은 CURL 일 것이다. ClusterIP 로 IP 가 할당되면 클러스터내에서 접근이 가능한데 이때에 다음과 같이 사용하면 된다.
|
1 2 3 |
$ kubectl run curl -it --rm --image curlimages/curl -- sh If you don't see a command prompt, try pressing enter. / $ |
curl 을 비롯한 ping, nslookup 도 가능하다.
Kubernetes
쿠버네티스에 프로메테우스(Prometheus) 오퍼레이터 설치하기
프로메테우스(Prometheus)는 모니터링 시스템을 말한다. 프로메테우스는 파일 기반의 타임시리즈(Time-Series) 데이터베이스다. 시스템의 메트릭스들을 수집하기 위해서는 익스포터(Exportor) 를 설치해야 한다. 이외에도 알람을 전달해주는 AlertManager 도 있는데, 전체적인 아키텍쳐는 다음과 같다. 프로메테우스는 쿠버네티스에서도 설치가 가능한데, 이글은 쿠버네티스에 프로메테우스 설치에 대한 글이다. 환경 환경은 다음과 같다. Kubernetes 버전: 1.20 Kubernetes Nodes: Master 3개, Worker 3개 Prometheus 설치 방법: Helm Operator 설치 프로메테우스(Prometheus) 설치는 매우 다양한데, 검색을 해보면 Helm 을 이용한 방법 그중에서도 오퍼레이터(Operator) 를 이용한 방법이 많이 소개 되어 있다. 여기서도 이 오퍼레이터를 이용한 방법을 […]
Kubernetes
Ingress Nginx
인그레스(Ingress) 는 쿠버네티스에 설치하는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스를 위해서는 인그레스 오브젝트를 설치해야 하는데, 이를 구현한 것들이 꽤 있지만 nginx 가 대표적이다. 여기서는 Ingress-Nginx 에 대해서 간단히 알아 본다. 설치전 고려사항 첫째로 일단 쿠버네티스에 서비스(Service) 에 고려 해야 한다. 쿠버네티스의 서비스는 클러스터내에 접속지점을 생성해 준다. ClusterIP, LoadBalancer, NodePort 세 가지의 타입이 존재한다. 문제는 LoadBalancer 타입인데, 이 타입을 지정해주면 EXTERNAL-IP 가 할당되어야 하지만 일반적인 환경에서는 할당되지 않는다. LoadBalancer 는 클라우드 서비스 제공 사업자를 […]
Kubernetes
Metallb 설치하기
쿠버네티스(Kubernetes) 의 서비스(Service) 에 타입에는 Loadbalancer, NodePort 등을 지원한다. 문제는 Loadbalancer 는 클라우드(Cloud) 서비스 사업자를 위한 것으로 AWS, GCP, Azure 에서 제공하는 Loadbalancer 를 위한 것이다. 그런데, 많은 쿠버네티스의 사례를 살펴보면 Loadbalancer 를 사용한 사례가 아주 많다. 그래서 굳이 클라우드 서비스 사업자가 아니라고 하더라도 Loadbalancer 를 사용할 수 있도록 해보자해서 만들어진게 바로 Metallb 이다. 필자는 KVM 리눅스 가상화에 쿠버네티스를 설치했다. KVM 가상 시스템의 게스트 OS 들은 브릿지 네트워크 모드로 이기 때문에 필자의 공유기에서 자동으로 아이피를 할당 받거나, 공유기의 대역에 IP를 […]
Kubernetes
쿠버네티스 수동 설치
쿠버네티스 설치는 kubeadm 명령어를 이용하면 손쉽게 자동으로 이루어 진다. HA 를 위한 설치에서는 좀 더 손이 더 가겠지만 어쨌거나 그것도 kubeadm 을 이용한다. 쿠버네티스 설치에 많은 시간을 들이는 것이 그렇게 현명해 보이지는 않을 수 있지만 쿠버네티스의 기본적인 구조를 이해하는데 수동 설치만큼 유용한 것도 없다. 인터넷을 검색해보면 쿠버네티스 수동 설치는 보통 ‘Hard way’ 로 많이 나온다. ‘힘든 방법’ 등으로 번역할 수 있는데, 하나하나 수동으로 설치를 하게 된다. 이 글이 어렵다면 ‘Kubernetes Hard way’ 로 검색하면 많은 자료를 얻을 수 있다. Requirements […]
Kubernetes
Docker, Kubernetes 네트워크
인터넷 검색을 하다보면 Docker, Kubernetes 네트워크에 관한 글이 많이 보인다. 기본적인 이론에서부터 응용까지 잘 설명된 글들이 꽤 많은데, 나는 눈에 보이는 상태를 한번 살펴보기로 했다. Docker 네트워크 Docker 를 처음 설치하면 어떤 상태일까? 먼저 Docker 를 설치한 리눅스 시스템의 네트워크 상태는 다음과 같다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
$ ip -c -br link lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> enp0s3 UP 08:00:27:e3:f6:8b <BROADCAST,MULTICAST,UP,LOWER_UP> docker0 DOWN 02:42:be:90:93:52 <NO-CARRIER,BROADCAST,MULTICAST,UP> $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:e3:f6:8b brd ff:ff:ff:ff:ff:ff inet 192.168.96.39/20 brd 192.168.111.255 scope global dynamic noprefixroute enp0s3 valid_lft 4524sec preferred_lft 4524sec inet6 fe80::d52d:e84a:d820:3cf/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:be:90:93:52 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever |
docker0 라는 네트워크 인터페이스가 생성되면서 172.17.0.1/16 아이피가 할당되었다. 그리고 이 인터페이스는 Bridge 다.하지만 인터페이스는 DOWN 상태다. Docker 를 막 설치하고 난 후에 이런 모습이다. Bridge 상태는 다음의 명령으로 확인이 가능하다.
|
1 2 3 4 5 6 |
$ nmcli connection show --active NAME UUID TYPE DEVICE enp0s3 9d696977-82ab-4f36-b2be-fccaf5bcee5c ethernet enp0s3 docker0 fd2e456f-93ea-43cf-8fd7-46aefe11a4a4 bridge docker0 $ bridge link show $ |
nmcli 를 보면 TYPE 에 […]
Kubernetes
메트릭 서버(Metric Server) 설치에 관한 오류들…
다양한 메트릭 서버 설치에 관한 오류들을 알아보자. kubectl top node Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)
|
1 2 |
$ kubectl top pod Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io) |
메트릭 서버(Metric Server) 의 파드(Pod)가 정상적으로 Running 상태라 하더라도 이와같은 오류 메시지를 만날 수 있다. 이 오류는 kube-apiserver 의 로그에 다음과 같이 관련 오류가 나온다.
|
1 |
Apr 23 15:49:33 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:33.330967 4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: Operation cannot be fulfilled on apiservices.apir>Apr 23 15:49:38 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:38.332227 4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.32.0.>Apr 23 15:49:43 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:43.333609 4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.32.0. |
뒤쪽에 삭제된 부분은 “net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)” 이다. 응답커넥션을 맺다가 안되서 timeout 으로 끝난 것이다. 이것은 kube-apiserver 다음의 커맨드 파라메터를 […]