전체 글150 Kubernetes Pod Pending 해결: 자원 부족·taint·PVC·스케줄링 점검 Kubernetes Pod가 Pending에 머무르면 이미지를 다시 빌드하기 전에 스케줄러가 노드를 배정했는지부터 보세요. Pending은 노드 배정을 기다릴 때뿐 아니라 컨테이너 설정이나 이미지 다운로드를 기다리는 단계에도 나타날 수 있습니다. FailedScheduling 이벤트와 Pod의 Node 값이 원인 분기의 출발점입니다.1. 먼저 이벤트와 Node 배정 여부를 확인하세요아래 예시는 읽기 전용 조회입니다. app은 실제 네임스페이스로, my-pod는 실제 Pod 이름으로 바꾸세요.kubectl get pod my-pod -n app -o widekubectl describe pod my-pod -n appkubectl get events -n app --sort-by=.lastTimestamp.. 2026. 9. 29. Docker daemon socket permission denied 해결: 권한·context·rootless 점검 permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock가 보이면 이미지나 컨테이너 문제라고 단정하지 마세요. 먼저 현재 CLI가 어느 Docker 데몬에 연결하려는지, 소켓이 존재하는지, 현재 사용자에게 접근 권한이 있는지를 분리해서 확인해야 합니다. 특히 단순히 소켓 권한을 모두에게 열면 로컬 보안 경계가 무너질 수 있습니다.1. 오류가 말하는 것은 무엇인가Linux Docker Engine의 기본 접속 경로는 Unix 소켓입니다. Docker 데몬 문서는 기본 소켓이 루트 또는 허용된 그룹의 접근을 받는다고 설명합니다. 이 오류는 데몬이 멈췄을 때 나오는 “Cannot conn.. 2026. 9. 29. 기업용 Redis 캐시 운영 선택: Amazon ElastiCache와 자체 구축 비용·복구 비교 서비스가 느려져 캐시를 도입하려는데 Redis 호환 서버를 직접 운영할지, Amazon ElastiCache를 사용할지 고민된다면 먼저 캐시가 사라졌을 때의 영향을 분류하세요. 다시 채울 수 있는 조회 캐시와 업무의 유일한 데이터 저장소는 복구 요구가 다릅니다. 관리형을 선택하면 서버 교체·패치 부담을 줄일 수 있지만, 데이터 모델·TTL·접속 실패 처리·비용 관리는 여전히 애플리케이션 팀의 책임입니다.1. 비교 대상: 자체 운영, ElastiCache 노드형, 서버리스ElastiCache는 Valkey·Redis OSS 호환 캐시를 관리형으로 제공합니다. AWS 배포 옵션 문서에 따르면 서버리스는 용량 계획을 줄이는 대신 지원 명령과 클라이언트 호환성 등 제약을 확인해야 하고, 노드형은 인스턴스·샤드·.. 2026. 9. 29. GitHub Actions와 GitLab CI 비교: 기업용 CI/CD 비용·러너·권한 선택 기준 팀의 CI/CD를 고를 때 “GitHub Actions와 GitLab CI 중 어느 쪽이 더 저렴한가”부터 묻기 쉽습니다. 하지만 저장소 위치, 러너 운영 방식, 승인 절차, 실행 시간과 산출물 보관량이 다르면 같은 분당 가격을 비교해도 결론이 틀립니다. 이미 GitHub에 코드를 두고 간단한 자동화를 시작한다면 Actions가 자연스러운 출발점입니다. GitLab의 저장소·보안·배포 기능을 함께 운영하거나 자체 러너 정책이 중요한 팀은 GitLab CI/CD를 같은 조건에서 시험해 보세요.1. 먼저 저장소와 실행 환경을 고정하세요GitHub Actions는 GitHub 저장소의 이벤트와 워크플로 파일을 중심으로 실행됩니다. GitLab CI/CD는 GitLab 프로젝트의 파이프라인과 러너를 중심으로 구.. 2026. 9. 29. Kubernetes ImagePullBackOff 해결: 이미지 태그·imagePullSecrets·네트워크 점검 AI로 제작한 개념 일러스트입니다. 다운로드 실패는 이미지 참조·인증·노드 연결 경로를 나누어 확인합니다.Kubernetes Pod가 ImagePullBackOff에 머물면 애플리케이션 로그부터 찾기보다 Pod의 이벤트를 먼저 확인하세요. 이미지를 내려받지 못해 컨테이너가 시작되지 않은 상태일 수 있습니다. 이미지 주소·태그, 인증정보와 네임스페이스, 노드의 네트워크·TLS·지원 아키텍처를 순서대로 좁히면 불필요한 재배포를 줄일 수 있습니다.1. ImagePullBackOff와 실행 뒤 장애 구분하기Kubernetes 이미지 공식 문서는 ImagePullBackOff를 이미지 다운로드 실패 후 간격을 늘려 재시도하는 상태로 설명합니다. 상태 이름 자체가 근본 원인은 아닙니다. 이벤트에 적힌 상세 오류를 .. 2026. 9. 28. Docker x509 인증서 오류 해결: unknown authority·사내 CA·프록시 점검 순서 AI로 제작한 개념 일러스트입니다. TLS 오류는 인증서를 검증하는 실행 환경과 신뢰 체인을 나누어 확인합니다.Docker에서 x509: certificate signed by unknown authority 오류가 나타나면 비밀번호부터 바꾸기보다 어느 실행 주체가 TLS 인증서를 검증하지 못하는지 확인하세요. docker pull 단계의 데몬, Docker Desktop의 호스트 환경, 컨테이너 안의 프로그램은 인증서를 신뢰하는 위치가 다를 수 있습니다. 같은 주소가 브라우저에서 열린다는 사실만으로 Docker에서도 신뢰된다고 판단하기는 어렵습니다.1. 오류가 발생한 위치부터 구분하기이미지 다운로드가 실패했는지, 이미 실행된 컨테이너에서 사내 API 호출이 실패했는지 기록합니다. 첫 번째는 레지스트리와.. 2026. 9. 28. 이전 1 2 3 4 ··· 25 다음
