default namespace 앱을 새로운 namespace로 옮길 때 이슈가 발생할 수 있다.


k8s는 기본적으로 기존 정보를 모른다. 

default namespace에 올린 service,ingress,pods는 그대로 둔채..

새로운 namespace에 service, ingress,pods는 뜬다.


이때 ingress는 같은 포트를 사용하기 때문에 에러가 당연히 발생한다.

디폴트의 ingress는 종료시키고, 새로운 namespace의 ingress는 떠있게 한다.

그리고 default service, pods도 일일이 종료 시킨다. 


다음과 같이 나오면 정상이다. 



$ kubectl get ingress

x


$ kubectl get ingress -n <새로운 namespace>

새로운 ingress


Posted by '김용환'
,


Service, Ingress 설정을 주고 ingress 확인하기


아래와 같은 k8s으로 kubectl apply 적용했다.

---
apiVersion: v1
kind: Service
metadata:
name: phantomjs-service
spec:
ports:
- port: 80
protocol: TCP
targetPort: 3001
selector:
app: phantom-server
---
apiVersion: app/v1beta2
kind: Ingress
metadata:
name: phantomjs-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
ingress.kubernetes.io/rewrite-target: /
ingress.kubernetes.io/proxy-body-size: 10m
nginx.org/client-max-body-size: 10m
spec:
rules:
- host: capture.internal.google.com
http:
paths:
- path: /
backend:
serviceName: phantomjs-service
servicePort: 80



 ingress-nginx 네임스페이스를 확인한다.


$ kubectl get pods -n ingress-nginx

NAME                               READY   STATUS    RESTARTS   AGE

default-backend-55d45476bb-q9cwd   1/1     Running   0          14d

ingress-nginx-controller-ff5ht     1/1     Running   0          1d






docker에서 다음을 실행하면 nginx 설정을 확인할 수 있다.

$ kubectl -n ingress-nginx exec -it ingress-nginx-controller-ff5ht /bin/bash

쉘) cat /etc/nginx/nginx.conf





지금까지의 작업을 한 커맨드로 사용해 namespace에 nginx ingress가 하나 밖에 없다면 다음과 같이 쉽게 볼 수 있다.


$ kubectl exec -it -n ingress-nginx $(kubectl -n ingress-nginx get pods | grep ingress-nginx-controller | grep Running | awk '{print $1}' | head -n 1) cat /etc/nginx/nginx.conf 



ingress docker 내부 vi로 보고 싶다면, vi가 설치가 안되어 있어서 보기 어렵다. '| vi - '를 추가한다.


$ kubectl exec -it -n ingress-nginx $(kubectl -n ingress-nginx get pods | grep ingress-nginx-controller | grep Running | awk '{print $1}' | head -n 1) cat /etc/nginx/nginx.conf | vi -





Posted by '김용환'
,


nginx를 ingress로 사용하는 kubernetes에서 body 크기(jpeg같은 image)때문에 ingress를 통과 못할 수 있다. 413 에러가 나타나는 이유이다.

이럴 때는 client_max_body_size를 설정한다.


ingress.kubernetes.io/proxy-body-size: 10m



참고

https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#custom-max-body-size

Posted by '김용환'
,

쿠버네티스 노드의 docker 버전 정보를 알고 싶다면 어떻게 해야 할까?



kubectl describe nodes를 호출하면 다양한 정보가 나오는데. 이때 docker를 grep하면  버전 정보를 확인할 수 있다. 


$ kubectl describe nodes | grep docker

 Container Runtime Version:  docker://17.3.2

 Container Runtime Version:  docker://17.3.2

 Container Runtime Version:  docker://17.3.2

 Container Runtime Version:  docker://17.3.2

 Container Runtime Version:  docker://17.3.2

 Container Runtime Version:  docker://18.6.3

Posted by '김용환'
,


# docker 새 버전 업그레이드하기


kubectl 실행할 수 있는 장비


$ kubectl drain 장비명

$ kubectl get nodes


장비명에서 docker를 업그레이드한다.


$ sudo systemctl stop docker

$ sudo apt remove docker-ce -y

$ apt list docker-ce -a


$ sudo apt install docker-ce="18.06.2~ce~3-0~ubuntu" -y

$ sudo systemctl restart kubelet




kubectl 실행하는 장비에서 장비를 스케쥴링하도록 한다. 

$ kubectl uncordon 장비명


Posted by '김용환'
,


도커 환경을 정리하는 커맨드는 다음과 같다.


docker container prune은 중지된 모든 컨테이너를 삭제한다.

docker image prune은 이름 없는 모든 이미지를 삭제한다.

docker network prune은 사용되지 않는 도커 네트워크를 모두 삭제한다.


docker volume prune은 도커 컨테이너에서 사용하지 않는 모든 도커 볼륨을 삭제한다.

docker system prune -a는 중지된 모든 컨테이너, 사용되지 않은 모든 네트워크, 하나 이상의 컨테이너에서 사용되지 않는 모든 이미지를 삭제한다. 따라서 남아 있는 컨테이너 또는 이미지는 현재 실행 중인 컨테이너에서 필요한 것이다.


Posted by '김용환'
,

kubernetes에 sidecar proxy라는 개념이 있다.

pod에는 일반적으로 하나의 container(image)를 띄우는데

함께 부가적으로 도커 이미지를 띄우는 경우를 말한다.



일반적으로 사용하는 tomcat app 앞에 apache나 nginx를 두고 싶을 때,

kibana 앞에 ldap 인증 부분(go, python)을 두는 앱서버를 두고 싶을때 사용되는 개념이다.


https://medium.com/@lukas.eichler/securing-pods-with-sidecar-proxies-d84f8d34be3e

Posted by '김용환'
,

보통 kubernetes pod을 재시작하려면 deployment 파일을 이용하는 경우가 많지만..


설정 파일 없이 확인하는 방법도 있다.



먼저 도커 이미지 이름을 얻는다.


아래 커맨ㄷ는 실제 컨테이너의 데타 데이터 이름과 컨테이너의 도커 이미지 이름을 얻는 커맨드이다.


$ kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort


ingress-nginx-controller-szb9s: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.19.0,

ingress-nginx-controller-ttq2h: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.19.0,

jenkins-8498fcb9b5-6n2vm: jenkins/jenkins:lts,

kube-apiserver-dkosv3-jenkins-master-1: gcr.io/google-containers/hyperkube-amd64:v1.11.5,

kube-apiserver-dkosv3-jenkins-master-2: gcr.io/google-containers/hyperkube-amd64:v1.11.5,

kube-apiserver-dkosv3-jenkins-master-3: gcr.io/google-containers/hyperkube-amd64:v1.11.5,




원하는 것은 바로 아래 커맨드이다. 메타데이터와 컨테이너 이름을 얻을 수 있다.


$ kubectl get pods -o=custom-columns=NAME:.metadata.name,CONTAINERS:.spec.containers[*].name

NAME                                                           CONTAINERS

jenkins-job-8f24e681-5b83-4f87-b713-69c86deedb22-25gsh-vjh9r   jnlp

jenkins-job-914tx-fthwt                                        jnlp

jenkins-8498fcb9b5-6n2vm                                    jenkins

my-release-mysql-65d89bd9c4-txkvn                              my-release-mysql








재시작을 진행한다. reboot 커맨드가 도커 안에 포함되어 있으면 다음처럼 실행한다.


$ kubectl exec jenkins-8498fcb9b5-6n2vm -c jenkins reboot



만약 다음 에러가 난다면, kill 커맨드를 사용해야 한다.


rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "exec: \"reboot\": executable file not found in $PATH"




kubectl exec jenkins-8498fcb9b5-6n2vm -c jenkins  -- /bin/sh -c "kill 1"



Posted by '김용환'
,


pod의 ip를 알려면 다음과 같은 커맨드를 사용한다.


$ bkubectl get pods

pod의 이름을 얻는다.


$ kubectl get pod <포트-이름> --template={{.status.podIP}}

10.10.10.10

Posted by '김용환'
,



쿠버네티스에서 

볼륨을 포함하는 statefulset이 종료되지 않으면,  (사실 deployment도 영향 줄 수 있도)

볼륨을 삭제(delete pvc) 커맨드를 실행하더라도 종료되지 않는다.



$ kubectl get pod -w

NAME       READY   STATUS    RESTARTS   AGE

consul-0   1/1     Running   0          28d

consul-1   1/1     Running   0          28d

consul-2   1/1     Running   0          28d

consul-3   1/1     Running   0          28d

consul-4   1/1     Running   0          28d



pv를 확인한다. 


$ kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE

pvc-46e015f0-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            Delete           Bound    default/datadir-consul-3   standard                26d

pvc-535563b9-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            Delete           Bound    default/datadir-consul-4   standard                26d

pvc-b07a2c23-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            Delete           Bound    default/datadir-consul-0   standard                26d

pvc-c32c35d9-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            Delete           Bound    default/datadir-consul-1   standard                26d

pvc-d420797e-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            Delete           Bound    default/datadir-consul-2   standard                26




$ kubectl get pvc

NAME               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE

consul-0   Bound    pvc-b07a2c23-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       26d

consul-1   Bound    pvc-c32c35d9-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       26d

consul-2   Bound    pvc-d420797e-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       26d

consul-3   Bound    pvc-46e015f0-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       26d

consul-4   Bound    pvc-535563b9-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       26d




$ kubectl delete pvc consul-0 consul-1  consul-2  consul-3 consul-4

persistentvolumeclaim "consul-0" deleted

persistentvolumeclaim "consul-1" deleted

persistentvolumeclaim "consul-2" deleted

persistentvolumeclaim "consul-3" deleted

persistentvolumeclaim "consul-4" deleted




$ kubectl get pvc

NAME               STATUS        VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE

consul-0   Terminating   pvc-b07a2c23-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       28d

consul-1   Terminating   pvc-c32c35d9-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       28d

consul-2   Terminating   pvc-d420797e-303d-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       28d

consul-3   Terminating   pvc-46e015f0-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       28d

consul-4   Terminating   pvc-535563b9-3041-11e9-a0e7-fa163ecffc2b   1Gi        RWO            standard       28d




Terminating 상태로 변경되었지만


volume이 지워지지 않는다. 계속 Terminating 상태이다.






statefulset을 삭제하자 마자 모두 삭제된다.



$ kubectl delete statefulsets consul

statefulset.apps "consul" deleted




$ kubectl get pod

No resources found.


$ kubectl get pvc

No resources found.


$  kubectl get pv

No resources found.


Posted by '김용환'
,