-
Notifications
You must be signed in to change notification settings - Fork 0
18.10.02
마지막 while 문은 pod 이 모두 run 될때까지 기다리는 부분
만약 안넘어가면 kubectl get pods 를 통해서 직접 확인해야 함.
반복 설치 과정에서 더미 등이 남아서 dns 러닝이 안됐을 수도 있음.
이럴 경우 가장 의심해야 할 것은 dns 서버.
pod 의 내용을 확인해야 함.
이것을 확인하기 위해선 k8s 에 대한 공부가 필요하며,
밑에부터는 TACO 에서 돌아가는 k8s의 pod 에 대한 설명이다.
노드가 여러 개가 되고, 어느 노드에 어떤 것이 있는지 모르기 때문에,
각 노드끼리 아이피를 알게 하기 위해서,
같은 아이피 체계 안에 있도록 하게끔 하는 것.
이를 overlay network 를 구성한다고 하며,
k8s에는 다양한 네트워크 플러그인이 존재하다.
그 중 하나가 calico이며, 여기선 그것을 사용한다.
route -en
여기서 cali 로 시작하는 interface 에서 넷마스크는 모두 255.255.255.255 이다.
(-> 즉, 아이피를 직접 줬다는 의미)
즉, 172.16.107.x 를 calico 로 제공하는 것.
이 때, 이를 저장하는 db가 필요하므로, etcd를 참조하고 있다.
위의 db 를 가지고 calico node 가 이를 관리하게 해준다.
+)
여기서 all-in-one 으로 설정했기에,
아이피 300 개 이상 할당해버리면 리소스를 많이 먹고 관리하기 힘들다.
calico 가 32-bit 네트워크를 구성을 해준다.
또한 BGP(Background Process ?)로 구성 해준다.
(각 pod 을 C 클래스에 종속되는 것이 아니라,
각 pod 들에게 아이피를 직접 할당하게끔 해 줌.)
kubernetes 클러스터의 api 역할을 함.
master1, master2, master3 >> api 를 띄워서 유저가 접근 가능하도록 함
(kube-ctl 명령어를 썼다는 것은 유저로부터 api 요청을 받게 함)
ls
cd ./kube
kubectl get pods -n kube-system 을 통해서 이름 확인 가능
kubectl logs -f kube-apiserver-taco-aio -n kube-system 에서 로그 확인
즉, api 서비스를 동작시키게 하는 pod 임.
pods 이 잘 작동하는 등의 관리함
namespace 등으로 pod 에 접근하게끔 함
즉, 도메인과 pod 의 아이피를 연결시켜주는 역할을 함
판단을 함 (뭘 ?)
dns 서비스를 auto-scaling 함
대시보드 제공
+) 대시보드를 들어가보는 방법 ?
(팟의 아피피를 외부에서도 접근 가능하도록 열어둬야 함)
kubectl patch svc kubernetes-dashboard -n kube-system --type='json' -p '[{"op":"replace","path":"/spec/type","value":"NodePort"}]'
그리고
kubectl get svc -n kube-system
따로 배포된 서비스를 가지고 이름을 갖고 다시 배포하게 해주는 역할
팟을 올리면 외부에서 접근할 수 있는데, 노드의 경로를 만들어 주는 proxy 역할을 함
(기본적으로 ip-table들을 제어하면서 pod 과의 연동 등을 관리함)
모든 node 에 설치되어 있어야 함.
만약 /etc/resolve.conf 에 아래 내용이 없으면 만들어야 함.
nameserver 10.96.0.10
nameserver 8.8.8.8
nameserver 8.8.4.4
search openstack.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
(설명)
10.96.0.10 이 dns 로 돼있으면 질의를 할 수있음.
(내가 dns 에서 어떤 아이피를 알고 있으면 그쪽으로 알려줌)
nslookup tiller-deploy.kube-system.svc.cluster.local
로 확인 가능
여기에 안 올라간 것이 하나 있음
그것이 kubelet 인데,
/etc/kubenetes/manifest/yaml
을 입력하면 다시 잘 올라간다.
(이것은 작동이 잘 안됐을 때 다시 작동시켜주는 명령어)
k8s 도 메타데이터를 관리할 데이터베이스가 필요하다.
이는 etcd 를 참조하면서 구현되며,
ps aux | grep etcd
를 통해 확인 할 수 있다.
즉, kube 의 데이터베이스는 etcd 라고 생각하면 된다.
(여기선 docker 로 띄워진 것을 알 수 있다.
kubesystem 으로 관리했기에, 아까 pod 확인하는 명령어에서 뜨지 않은 것이다.)
kubectl get svc -n kube-system
-> k8s 아이피 확인
docker ps | grep scheduler
-> 여기서 id 를 찾아야 함
docker rm -f 0d971e17ecd6(id값)
-> 위에서 찾은 id로 팟 죽이기
kubectl get pod -n kube-system
-> kube pod 값 얻기 (이를 통해서 밑의 delete 가능 ?)
kubectl delete pod -n kube-system
-> kube 로 kill 하기
docker ps -a
-> 죽은 docker 로그 보기
이를 통해 모든 docker 컨테이너를 찾고,
uid 로 로그를 확인하면 됨.
- 오류 해결하는 명령어들
kubectl get pods -n ‘pod 이름’
-> pod 을 올리는 과정에서 에러가 발생했을때
kubectl logs pod ‘컨테이너 이름’
-> pod 내에서 컨테이너 안에서 에러가 발생했을 때
k8s의 dashboard에 접속한 이후 …
key 나 token 을 사용하여 권한 인증을 함.
권한은 RBAC 이라는 방식을 사용함
(-> Role 을 지움으로써 접근 가능 여부를 확인하는 방식)
이 때, 내부에서 api 에 접근하기 위해선 pod 에서 권한이 따로 필요한데,
이를 service-account 라고 한다.
namespace 가 있고,
밑에 각 객체들이 있는데 … (service, pod, pvc, cm 등등 … )
이 모든 것이 rollbase 로 관리가 됨.
ex)
dashboard 는 kube-system 이라는 namespace 에 존재.
kube-system 의 default 라는 것.
즉, kube-sysyem 의 default 에 role 을 줄 것임
이를 클러스터 롤 바인딩(cluster role binding)이라고 함.
(볼 수 있는 모든 권한을 줄 것임)
crb.yaml 을 만들고
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
를 입력
그리고
kubectl apply -f crb.yaml