colima, podman

맥북에선 docker desktop(docker client/command-tools과 별개로 docker desktop은 UI를 지원하는 데몬(dockerd)으로 동작)을 사용했는데 유료라 무료 대체제를 알아보자.

참고로

linux 라면 podman 이 좋을것 같고

mac 에선 vm 시작이 좀 더 빠르고 기존 docker client 를 계속 사용할 수 있고 k8s 환경 구성도 쉬워 colima 가 좋은것 같다.

#####

colima + docker client

colima(https://github.com/abiosoft/colima)는 docker desktop 을 대신하는 데몬이다.

VM + container runtime(docker/containerd/incus) + docker api 를 제공한다.

# 설치

brew install colima

# 4cpu, 4GiB 메모리 VM 생성

colima start --cpu 4 --memory 4

# colima 를 stop 하지 않고 맥을 종료했다면 다음번 colima start 할때 다음과 같은 에러가 발생할 수 있다.

# FATA[0002] error starting vm: error at 'starting': exit status 1

# 이 경우 강제 종료하고 다시 시작하면 된다.

colima stop --force

# docker 명령(client)을 그대로 사용하면 된다.

# nginx 이미지 다운로드

docker pull nginx:latest

# nginx container 실행

docker run -d -p 8080:80 --name colima_nginx nginx:latest

# nginx container 리소스 모니터링

docker stats colima_nginx

# nginx container log 모니터링

docker logs -f colima_nginx

# ab(ApacheBench)로 -t 60 초로 부하를 줬을때 리소스 현황

# k8s 환경으로 띄우기

# cpu, mem 변경시 colima stop 후 다시 cpu, mem 변경해서 시작한다.

colima stop

colima start --cpu 4 --memory 8 --kubernetes

# 상태 정보

colima status

# instance 리스트

colima list

# kubernetes cluster 재설정(초기화, 설치된 리소스들은 모두 지워진다)

colima k8s reset

# kubectl config 정보 확인시

colima ssh -- cat /etc/rancher/k3s/k3s.yaml

# ingress nginx controller 설치

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

# 이제 kubectl 로 일반 k8s 처럼 사용할 수 있다.

# colima 삭제(k8s 설정등 지우고 새로 시작할때)

colima delete

#####

podman machine + podman

podman(https://github.com/containers/podman)는 docker 데몬,client 사용없이 별개의 환경이으로 구성할 수 있다.

docker 데몬 같은게 없는 daemonless 구조이고 로 호스트에서 root 권한없이 일반 사용자 계정으로 컨테이너를 실행하는 rootless container 방식 시스템 전체에 영향을 주지 않아 보안성이 좋다고 한다.

# 설치

brew install podman

# 실행중인 vm list 파악

podman machine list

# podman machine(vm) 시작

podman machine init --cpus=4 --memory=4096

podman machine start

# vm 삭제시

# mac 에서 이름이 podman-machine-default 하나로 고정되어 있다.

podman machine rm podman-machine-default

# nginx 이미지 다운로드(docker client 가 아니라 이미지 주소가 다르다.)

podman pull docker.io/library/nginx:latest

# nginx container 실행

podman run -d -p 8081:80 --name podman_nginx nginx:latest

# nginx container log 모니터링

podman logs -f podman_nginx

# ab(ApacheBench)로 -t 60 초로 부하를 줬을때 리소스 현황

# vm 접속해 k3s 등을 직접 설치하는 등 kubernetes 환경 구성이 복잡하다.

cloudflare down

2025-11-18 cloudflare down

cloudflare 인프라를 사용하는 chatgpt, perplexity, cluade...등이 접속이 안된다.

이와중에 자체 인프라를 사용하는 구글의 gemini 는 잘된다.

구글은 자체 인프라가 있지만 나머지는 그렇지 못하다.

작은 회사가 급성장하면서 유명해지고 수십조를 벌었지만 수십년간 쌓아온 구글의 인프라는 짧은 시간에 채워넣을 수 없고 그래서 cloudflare 라는 회사도 같이 클 수 있었다.

어쩌면 당연한 흐름이고 이걸 탓하면 안될것 같다.

이번과 같은 인프라/클라우드로 전세계 패닉 사건은 최근 몇년간 꽤 심심치 않게 본다.

2024년 7월 ms 클라우드 장애 https://marketin.edaily.co.kr/News/ReadE?newsId=02833926638956160

2025년 10월 aws 장애 https://www.bbc.com/korean/articles/c5y9dw49px5o

모든 것들이 클라우드로 서비스되면서 아주 커다란 크루즈에 올라탄 공동운명체가 된것 같다.

크루즈는 화려하고 편하고 좋지만 한번 사고나면 생각만해도 끔직하다.

클라우드로 대세화 되는건 거대한 흐름이지만 클라우드는 점점 더 많은 서비스가 생기고 복잡해진다.

20년전인가 암튼 오래전 클라우드라는 단어가 떠오르던 초창기만 하더라도 사내에서 원격 접속해서 사용하는 베어메탈 서버에 사원들이 각자 자기의 계정을 만들어 접속하는 형태였다.

그리고 자신의 계정에서 서비스를 올리는 형태였다.

하지만 virtualmachine, domain, loadbalancer, k8s, db, ai 까지 진짜 비지니스 로직만 신경쓰면 모든걸 클라우드가 해주는 시대가 됐다.

어떤 회사 클라우드를 사용하냐에 따라 그 사용방법을 숙지해야 되고 이것도 스펙이 된다.

이런 거대하고 복잡한 클라우드 서비스를 운영하려면 또 그만큼의 사람이 필요했고 많이 채용됐다.

그런데 코로나,ai시대를 거치면서 인력=비용이라는 문제가 발생했고 특히 북미에서는 빅테크 기업들이 필두로 해고 바람이 불었다.

1년전 쯤인가 cloudflare 직원이 해고되는 영상을 봤다.

aws, microsoft 도 기술직도 포함해 만명단위의 많은 직원을 내보냈다.

이런 기사를 볼때 처음에 아 이렇게 직원이 없어도 회사가 돌아가는 구나.

그 많은 사람들이 잉여 인력이 될 수 있구나하는 생각이 들었다.

그렇게 사람들이 내보내도 한동안 서비스에 문제가 없어 보였다.

그런데 이런 장애를 겪어 보니 어떤 사람을 내보냈고 내보낸 사람의 부재로 이런일이 발생하진 않았나 하는 생각이 든다.

어디서 본것 같은데 사람을 자를때 능력있고 우수한 직원을 내보내는게 아닌 부서단위로 전체를 내보내는 방법을 쓴다고 한다.

돈을 못버는 부서, ai 가 쉽게 대체할 수 있는 부서, 그런데 이들 부서들이 지금 보기엔 필요없을지 모르는데 한달,1년 후에 어떤 사이드 이펙트가 있을지 어떻게 모두 알까?

2025년 10월에 있었던 AWS US-EAST-1 지역 장애는 단순한 기술 결함이 아니라, 핵심 인력 유출로 인한 조직적 약화의 신호로 분석되는 말도 있다.

https://news.hada.io/topic?id=23806

cloudflare 자르는 것도 그렇고 어떤 기준에 의해서 납득이 될 수 있는 이유가 있어야 하는데 너무 해고를 쉽게 한건 아닐까?

물론 ai 인간을 대체한다고 떠드는 세상이고 언제간 ai가 인간을 대신에 많은걸 대신할것은 분명해 보인다.

그래도 아직 ai가 완벽하지 않은데 잘못된 기준과 판단으로 인재들이 퇴출되고 있지는 않는지 잘 살펴야할것 같다.

해고에 모두를 만족시킬 수 있는 합당한 이유가 있을까만은 지금 천명, 만명등 숫자만 크게 부각돼 질이 아닌 양으로 비용절감만을 목표한다면 이런 전세계 장애가 아니더라도 그 회사 어딘간 탈이나고 또다른 재난의 작은 불씨가 남을것 같다.

비용절감을 위해 대부분 직원은 그냥 소모품으로 보고 ai만 바라보는 리더들은 살을 빼야지 다리는 자르는 대수술이 능사가 아니라는걸 알았으면 좋겠다.

아주 커다란 크루즈는 최첨단 항해 기능과 최신 엔진등으로 항해사, 엔지니어들의 수는 줄일 수 있지만 뛰어난 항해사 엔지니어 없이 현재 수준의 ai 가 모든걸 통제하는 배를 믿고 오를 여행객들이 얼마나 될지 생각해 보자.

empty ingress status

새로 생성한 ingress 가 실제 loadBalancer ip 가 있고 동작하는데 status 가 다음과 같이 빈값으로 되는 경우가 발생했다. (kubectl get ingress > address 이 빈값으로 나온다.)

status:

  loadBalancer: {}

ingress-controller 가 해당 ingress 상태 업데이트를 해주기 위해선

ingress annotations 에 변화(추가,삭제)를 주어 ingress controller 가 이벤트를 감지할 수 있도록 했다.

metadata:

  annotations:

    ysoftman-test: "test" # 아무 키,값 추가

annotations 에 추가 후 k events 로 확인하니 ingress 변경으로 인한 이벤트가 발생했다.

하지만 아직도 status 값은 채워지지 않고 빈값으로 나오고 있었다.

ingress-controller 로그를 확인해보면 특이한 에러는 없었다.

k logs ingress-controller-xxxxx -n kube-system --timestamps --since=1m

[방법1]

ingress 를 삭제 후 다시 생성한다.

[방법2]

ingress-controller pod 재시작하면 ingress 리소스를 다시 읽어 업데이트한다.

kubectl rollout restart deployment ingress-controller-deployment -n ingress-controller