import pandas as pd
print(pd.__version__)
cs


Traceback (most recent call last):

  File "~\Anaconda3\lib\site-packages\IPython\core\interactiveshell.py", line 3343, in run_code

    exec(code_obj, self.user_global_ns, self.user_ns)

  File "<ipython-input-2-22947d009327>", line 1, in <module>

    runfile('D:/Project_CTLab/Hong_Test2/pandas.py', wdir='D:/Project_CTLab/Hong_Test2')

  File "C:\Program Files\JetBrains\PyCharm 2020.2.3\plugins\python\helpers\pydev\_pydev_bundle\pydev_umd.py", line 197, in runfile

    pydev_imports.execfile(filename, global_vars, local_vars)  # execute the script

  File "C:\Program Files\JetBrains\PyCharm 2020.2.3\plugins\python\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile

    exec(compile(contents+"\n", file, 'exec'), glob, loc)

  File "D:/Project_CTLab/Hong_Test2/pandas.py", line 1, in <module>

    import pandas as pd

  File "C:\Program Files\JetBrains\PyCharm 2020.2.3\plugins\python\helpers\pydev\_pydev_bundle\pydev_import_hook.py", line 21, in do_import

    module = self._system_import(name, *args, **kwargs)

  File "D:\Project_CTLab\Hong_Test2\pandas.py", line 3, in <module>

    print(pd.__version__)

AttributeError: partially initialized module 'pandas' has no attribute '__version__' (most likely due to a circular import)


pandas 모듈 불러오면서 파일명을 pandas.py 로 저장했더니...ㅋㅋ







WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

PyCharm + Anaconda + Tensorflow 에 처음 손대면서 생긴일.

  • PyCharm 은 사이트에서 받아서 설치하고,
  • Anaconda 도 사이트에서 받아 설치하고,
  • Tensorflow 는 pip 로 설치하고...


하지만 PyCharm 에서 별 설정없이  import tensorflow  를 날렸다가는,


ImportError: DLL load failed while importing _pywrap_tensorflow_internal: 지정된 모듈을 찾을 수 없습니다.

...or...

ModuleNotFoundError: No module named 'tensorflow'


식의 에러메시지를 만나게 된다.


설치가 되어 있음에도 모듈을 찾을 수 없다는 것은 해당 IDE 에서 tensorflow 를 사용할 수 있도록 설정 등이 제대로 되어 있지 않음을 뜻하는거 같은데...


만약 Anaconda 설치 전에 python 을 별도로 설치했거나, PyCharm 설치 후에 새 프로젝트 생성하면서 default 로 대충 넘기다 보면 나도 모르게 가상환경으로 인터프리터가 생성 되던지.. 해서 일단 인터프리터는 두 이상이 되어 있을 수 있다. 그리고 현재 인터프리터에서 tensorflow 를 사용할 수 있도록 준비가 되어 있는지를 확인해야 한다.


난 현재 인터프리터에서 pip 로 tensorflow 설치 및 확인하였고, PyCharm 탐색기의 External Libraries, ~/anaconda3/Lib/site-packages 에서도 확인했는데 tensorflow 패키지는 확실히 있다. PyCharm 문법에서도 오류 없이 타이핑된다. 하지만 해당 파일을 실행시키면 ImportError...


더 알 수 없는 것은 PC 두 대에 동일하게 설치했는데 한 대는 이상이 없고 한 대만 ImportError 가 발생한다. 같은 2.3.1 버전인데... 인터넷 검색 결과 ImportError 에 관련된 비슷비슷한 에러가 상당히 많다. 그나마 가능성이 있을 것 같은 두 가지 원인을 찾아냈다.



두 PC 모두 하드웨어 사양은 동일했는데, 에러없이 정상적으로 구동된 PC 는 위 드라이버가 모두 설치되어 있었다. (내 손으로 깔은 기억은 없음...)


  • Microsoft Visual C++ 2017 Redistributable(x64)
  • NVIDIA CUDA Visual Studio Integration 10.0
  • NVIDIA Nsight Visual Studio Edition 6.0


에러난 PC에 하나하나 깔아보려고 했는데  vc_redist 2015-2019  를 설치하자마자 ImportError 문제가 해결이 됐다...; 참고로 Visual C++ 재배포 가능 패키지란, Visual C++ 이 설치되어 있지 않은 컴퓨터에 Visual C++ 라이브러리의 런타임 구성 요소를 설치하여 Visual C++ 로 개발된 응용 프로그램을 실행하게 해주는 패키지이다.


일단 되서 다행인데 vc_redist 2015 가 이미 깔려 있었는데 안됐던것도 억울하고,

에러도 _pywrap_tensorflow_internal 라고 나와 있으면 내가 어찌 아냐? 그것도 억울하고,

그렇게 중요한 파일이면 vc_redist 파일을 필수로 설치하게 하던지... 무식이 가장 억울하다... 






WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret



Master


위 그림은 쿠버네티스 클러스터의 아키텍처이다. 좌측의 마스터 컴포넌트는 클러스터의 제어영역(control plane) 을 제공하여, 클러스터에 관한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응한다. 마스터 컴포넌트는 클러스터 내에 어떤 노드에서든 동작할 수 있지만, 일반적으로 클러스터와 동일한 노드 상에서 구동시킨다. 아래는 마스터 내에서 동작하는 바이너리 컴포넌트들이며 쿠버네티스 초기화시 자동 설치된다.


kube-apiserver

쿠버네티스 API 로, 외부/내부에서 관리자의 원격 명령을 받을 수 있는 컴포넌트이다.


etcd

모든 클러스터 데이터를 저장하는 고가용성 키-값 저장소로, etcd 데이터에 대한 백업 계획은 필수이다.


kube-scheduler

생성된 파드를 노드에 할당해 주는 컴포넌트이다. 이것을 스케줄링이라 하며, 리소스/하드웨어/소프트웨어/정책/워크로드 등을 모두 참고하여 가장 최적화된 노드에 파드를 배치하게 될 것이다.


kube-controller-manager

아래의 컨트롤러들을 구동하는 컴포넌트이다.

- Node Controller : 노드가 다운되었을 때 알림와 대응에 관한 역할을 한다.

- Replication Controller : 지정된 수의 파드들을 유지시켜 주는 역할을 한다.

- Endpoints Controller: 서비스와 파드를 연결시켜 엔드포인트 오브젝트를 만든다.

- Service Account & Token Controllers: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.



Node


우측 하단의 노드 컴포넌트(Minions) 는 마스터 컴포넌트에 의해 관리되며 VM 이나 물리 장치가 될 수 있다. 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공한다. 아래는 노드 내에서 동작하는 바이너리 컴포넌트들이며 노드 오브젝트 생성시 자동 설치된다.


kubelet

클러스터의 각 노드에서 실행되는 에이전트로, 컨테이너들이 파드에서 실행 중인지, 이상이 없는지 확인한다.


kube-proxy

호스트 상의 네트워크 규칙으로 커넥션 포워딩을 수행함으로서 쿠버네티스 Service 가 가능하도록 한다.


Container Runtime

컨테이너 런타임은 컨테이너의 동작을 책임지며, 쿠버네티스에서 지원하는 컨테이너 런타임은 다음과 같다. 

Docker, containerd, cri-o, rktlet, Kubernetes CRI (Container Runtime Interface) 구현체.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

쿠버네티스에서는 배포 방법으로 블루/그린 배포, 카나리 배포, 롤링 업데이트 등을 사용할 수 있다. 롤링 업데이트 방식은 운영중인 어플리케이션의 파드 수를 하나씩 줄이고, 새로운 어플리케이션의 파드 수를 하나씩 늘려가며 변경하는 방법이다. 쿠버네티스는 어플리케이션 이미지를 업데이트 하면 롤링 업데이트 방식으로 배포를 진행할 것이다. 쿠버네티스에서 배포 업데이트는 버전으로 관리되고, 이전의 안정적인 버전으로도 복구가 가능하다.


다음 테스트는 kubernetes-bootcamp:v1 이미지를 사용 중인 서비스 환경에서 v2 이미지로 교체하였을 때 어플리케이션의 배포 진행을 파악하고, 다시 v1 이미지로 복원하는 시나리오 이다.


4개의 파드에 kubernetes-bootcamp:v1 이미지를 구동하여, 이미 서비스로 운영중임을 확인.


$ kubectl get deployment -o wide
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS            IMAGES                                         SELECTOR
kubernetes-bootcamp   4/4     4            4           11m   kubernetes-bootcamp   gcr.io/google-samples/kubernetes-bootcamp:v1   run=kubernetes-bootcamp
cs


해당 deployment 에 어플리케이션 이미지를 교체할 때,  kubectl edit deployment  명령을 사용하거나  kubectl set image  명령을 사용할 수 있다.


$ kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
cs


위 명령은 deployment 에 다른 이미지를 사용하도록 변경하고, 롤링 업데이트를 시작하도록 한다. 업데이트 확인.


$ kubectl get deployment -o wide
NAME                  READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS            IMAGES                             SELECTOR
kubernetes-bootcamp   4/4     4            4           26m   kubernetes-bootcamp   jocatalin/kubernetes-bootcamp:v2   run=kubernetes-bootcamp
cs


잠시 후에 서비스 ip 로 접근해 보면, 다음과 같이 새로운 v2 버전의 파드에 로드 밸런싱 되는 것을 확인할 수 있다.


$ curl service_ip
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-nqlrr | v=2
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-tjdrs | v=2
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-b6sdv | v=2
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-sr2aw | v=2
cs


그렇다면 업데이트 과정을 살펴보자.


$ kubectl describe deployment
Scaled up replica set kubernetes-bootcamp-6bf84cb898 to 4
Scaled up replica set kubernetes-bootcamp-5bf4d5689b to 1
Scaled down replica set kubernetes-bootcamp-6bf84cb898 to 3
Scaled up replica set kubernetes-bootcamp-5bf4d5689b to 2
Scaled down replica set kubernetes-bootcamp-6bf84cb898 to 2
Scaled up replica set kubernetes-bootcamp-5bf4d5689b to 3
Scaled down replica set kubernetes-bootcamp-6bf84cb898 to 1
Scaled up replica set kubernetes-bootcamp-5bf4d5689b to 4
Scaled down replica set kubernetes-bootcamp-6bf84cb898 to 0
cs


새로 생성된 ReplicaSet(5bf4d5689b) 의 파드 수가 하나씩 늘어나고, 동시에 ReplicaSet(6bf84cb898) 의 파드 수가 줄어들며 롤링 업데이트가 진행되는 것을 확인할 수 있다. 




만약에 경우에 이전 버전의 업데이트로 돌아가려면  rollout undo  명령으로 가능하다.


$ kubectl rollout undo deployments/kubernetes-bootcamp
deployment.extensions/kubernetes-bootcamp rolled back
 
$ curl service_ip
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-nqlrr | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-tjdrs | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-b6sdv | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-5bf4d5689b-sr2aw | v=1
cs


여기서 또 다시 rollout undo 명령을 실행하면 v1 버전보다 더 예전의 업데이트가 아닌 바로 전인 v2 버전으로 다시 돌아가는 것에 주의하자.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

파드에서 어플리케이션이 비정상 작동을 할 경우에 대비하여 Liveness/Readiness Probe 를 설정할 수 있다. Liveness Probe 는 컨테이너가 정상적으로 구동 중 인지를 체크할 수 있다. 결과가 정상이 아니면 컨테이너를 재시작한다. Readiness Probe 는 파드가 트래픽을 처리할 준비가 되어 있는지를 체크한다. 결과가 정상이 아니면 해당 파드는 로드밸런스에서 제외된다. 두가지 Probe 에 대하여 설정한 대로 노드의 kubelet 이 주기적으로 상태 체크를 하게 되며, 결과가 비정상일 경우 해당 파드는 not ready 상태로 변경된다. 


아래처럼 readiness/liveness probe 를 가진 파드를 생성해 보자.


apiVersion: v1
kind: Pod
metadata:
  name: "healthy-monolith"
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"
      livenessProbe:
        httpGet:
          path: /healthz
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 15
        timeoutSeconds: 5
      readinessProbe:
        httpGet:
          path: /readiness
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        timeoutSeconds: 1
cs


각 Liveness/Readiness Probe 에 대해서 체크하는 방법으로는 Command / HTTP / TCP 등이 있는데 위 예제에서는 HTTP 를 사용하였다. livenessProbe 의 경우 http://ip:81/healthz 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. readinessProbe 도 마찬가지로 http://ip:81/readiness 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. initialDelaySeconds 는 컨테이너가 준비되고 probe 를 실행하기 까지의 대기 시간이다. periodSeconds 는 probe 체크를 반복할 시간 설정이다. 



Liveness 테스트


아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 컨테이너의 restart 카운팅이 늘어나며, 컨테이너가 자동으로 재시작 될 것이다.


$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
 
$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/healthz/status
$ curl http://127.0.0.1:10081/healthz/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
healthy-monolith   0/1       Running   1         30m
healthy-monolith   1/1       Running   1         30m
healthy-monolith   0/1       Running   2         31m
healthy-monolith   1/1       Running   2         31m
cs



Readiness 테스트


아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 해당 파드는 not ready 상태가 되며 로드밸런스에서 제외되는데, 로드밸런스 테스트는 생략한다 ^^;


$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0          13m
healthy-monolith   0/1       Running   0          16m
healthy-monolith   1/1       Running   0          17m
healthy-monolith   0/1       Running   0          17m
 
$ kubectl describe pods healthy-monolith
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
 
Events:
  Type    Reason     Age   From                                              Message
  ----    ------     ----  ----                                              -------
  Normal  Scheduled  1m    default-scheduler                                 Successfully assigned default/healthy-monolith to gke-bootcamp-default-pool-bb4d9176-tpk5
  Normal  Pulling    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  pulling image "kelseyhightower/monolith:1.0.0"
  Normal  Pulled     1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Successfully pulled image "kelseyhightower/monolith:1.0.0"
  Normal  Created    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Created container
  Normal  Started    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Started container
 Warning  Unhealthy  8s (x15 over 2m)  kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Readiness probe failed: HTTP probe failed with statuscode: 503
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret