지금 집에 있는 서버(mac mini 2009)에서 nginx를 이용해서 블로그를 호스팅하는데 port를 구분해서 외부에 노출하고 있다. 외부에서의 >접근을 위해 NodePort를 사용하고, 각 nginx instance는 서로 다른 port를 이용하고 있는데 port번호가 아니라 URL 경로를 이용해서 서로 다른 서비스를 이용할 수 있는 reverse proxy 기능을 사용하면 좀 더 깔끔할 듯 하다. Kubernetes에서는 ingress와 ingress controller를 이용해서 이 reverse proxy를 구현할 수 있다고 한다. Kubernetes에서는 ingress는 기본적으로 제공하는 object 지만, ingress controller는 제공하고 있지 않아, 별도로 설치해야 한다.
$ sudo apt install -y cockpit sssd-dbus $ sudo ufw allow 9090/tcp ; sudo systemctl start cockpit` $ ss -tunlp |grep 9090 tcp LISTEN 0 4096 *:9090 *:* CPU load 정보가 주기적으로 100%까지 튀네. 거의 10초 단위로. 뭘까 여러 개의 리눅스 서버가 있는 경우 한 곳에 추가해서 single glass of pane을 만들 수도 있다. 추가된 서버들은 dashboard에서 drop list로 보여지므로 원하는 대상을 선택
How to change IP address of k3s By default, as k3s operates in the local host, it is not possible to connect from other host.
To get the server Ip address,
$ kubectl config view --raw |grep server server: https://127.0.0.1:6443 The listening server IP address can be specified by giving parameter in running the k3s binary.
K3s configuration is on /etc/systemd/system/k3s.service
$ cat /etc/systemd/system/k3s.service [Unit] Description=Lightweight Kubernetes Documentation=https://k3s.io Wants=network-online.target After=network-online.target [Install] WantedBy=multi-user.
Use the Secret and ConfigMaps $ cat my-secret.yaml apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque stringData: WSO2_CLOUD_ORG_KEY: "mycompany" WSO2_CLOUD_EMAIL: "sample-email@wso2.com" WSO2_CLOUD_PASSWORD: "password" $ kubectl apply -f my-secret.yaml secret/mysecret created From Using Kubernetes Secrets as Environment Variables
spec: containers: - env: - name: WSO2_CLOUD_ORG_KEY valueFrom: secretKeyRef: name: mysecret key: WSO2_CLOUD_ORG_KEY ... apiVersion: v1 kind: Secret metadata: name: my-tokens type: Opaque stringData: pinboard_key: "FIXME" pocket_consumer_key: "FIXME" pocket_access_token: "FIXME" slack_api_token: "FIXME" slack_events_token: "FIXME" slack_verification_token: "FIXME" slack_signing_secret: "FIXME" telegram_token: "FIXME" telegram_api_id: "FIXME" telegram_api_hash: "FIXME" $ kubectl apply -f my-tokens.
Problem CronJob이 지정된 시간에 잘 동작했는 지 확인해 본 결과 이상한 점을 발견했다.
오후 2시 32분에 CronJob 의 동작을 확인했는데 이전에 실행된 시간이 4시간 32분 전이라고, 즉 새벽 1시가 아니라 오전 10시에 실행이 되었다는 나오는 것이다.
$ date Sat Oct 10 14:32:36 KST 2020 $ kubectl get cronjob NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE pocket-stat 0 1 * * * False 0 4h32m 14h 혹시 10시를 1시로 잘못 설정했나 하고 kubectl describe cronjob 명령으로 확인해 봤지만 schedule 정보는 정상적으로 설정되어 있었다는.
서재 방을 뒤집으면서 이참에 책상 밑, 뒤 등에 숨겨(?)놨던 맥미니, 공유기, 나스 등을 나름 랙에 모아놓고, 랜선이 나오는 바로 벽 바로 옆에 뒀다. 그 덕에 벽에서 책상쪽으로 건너가기 위해 바닥에 있던 선 들이 이제 1개로 줄었다. 이전에는 전원선 2개, 유선 랜 2개 였는데 이제는 전원선 하나만 보냈다는.
덕분에 바닥이 깔끔해 지긴 했는데 랙이 너무 비좁다.
IKEA 칼락스가 하나 있으면 딱 일 것 같은데. 당근에서 저렴하게 하나 안 나오나?
만일 job을 일정 주기 혹은 특정 시간에 실행시키려면 CronJob resource를 만들어 사용하면 된다.
Job과 CronJob간의 관계는? CronJob에 대한 설명에 따르면 CronJob정의에 기술한 특정 시간이 되면 CronJob이 Job을 실행한다고. 그리고 그 Job이 Pod를 실행한다.
그럼 Job을 위한 resource 정의와 CronJob을 위한 resource 정의를 각각 정의해야 하나? 그렇지는 않은 듯. CronJob의 정의 파일을 보면 JobTemplate 항목이 Job에서 볼 수 있는 Template과 유사한 container spec 등을 가지고 있다. 물론 CronJob 에서만 유효한 schedule spec 등을 추가로 가지고 있긴 하지만.
한 번 실행되면 데몬 처럼 계속해서 동작하는 앱이 아니라 필요한 일을 수행하고 종료되는 앱도 있다. 실행된 시점에 필요한 일을 수행하고 종료하는 형태로 예를 들면 특정 위치에 있는 파일을 처리하고 종료한다거나, 실행된 시점에 외부 서비스에서 필요한 정보를 가져와 어딘가 저장하는 등의 일을 하는. 이런 종류의 앱을 kubernetes에서 Deployment로 배포한 경우 해당 앱은 자신이 해야 할 일을 정상적으로 수행하고 종료되지만, kubernetes scheduler 입장에서는 해당 container가 (의도하지 않게) 종료된 것으로 판단하여 다시 복구하는 절차를 수행한다.
Install InfluxDB with helm GitHub - influxdata/helm-charts: Official Helm Chart Repository for InfluxData Applications 가 helm chart를 이용한 설치법을 제공하는 공식 페이지.
helm repo add influxdata https://helm.influxdata.com/ $ helm repo list WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/cychong/.kube/config WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/cychong/.kube/config NAME URL myhelmrepo https://cychong47.github.io/helm-chart/ infracloudio https://infracloudio.github.io/charts influxdata https://helm.influxdata.com/ $ helm search repo influxdata NAME CHART VERSION APP VERSION DESCRIPTION influxdata/chronograf 1.
혹시나 했더니 사진 파일 형식이 JPEG이 아니라 HEIC(High Efficiency Image File) 였다는.
아이패드에서는 사진을 찍지 않고, 아이폰으로만 사진을 찍고 있는데, 사진을 Mac으로 옮길 때 사용하는 PhotoSync에서는 파일 변환 기능을 켜서 자동으로 JPG로 변환하고 있으니 거기서 올린 사진은 아닌 듯 하고, iPad에서 iOS shortcut을 이용해서 git repo에 직접 사진을 업로드하는데, 이때 올린 사진이 iPhone에서 HEIC로 저장하고, iCloud를 통해 iPad로 동히과된 사진이었다.
iOS Shortcut에서는 사진의 크기를 resize만 해서 올리고 있어서 그랬다는.
사진을 그냥 Mac에서 열었을 때는 전혀 문제 없이 열리고, 같은 MD 파일에 정상적으로 표시되는 다른 JPG 파일을 포함시켜도 잘 출력이 되서 찾기가 힘들었는데 화면에 표시가 잘 되는 사진과 잘 되지 않는 것 사이에 무슨 차이가 있나 하고 확인한 exiftool에서 단서를 찾은 것이다.