Kubernetes: RC 및 Pod에서 Pod 지정 시 log-driver 및 log-opt 정의

/ cc @ kubernetes / rh-cluster-infra

흠, 우리는 아마도 이 클러스터 전체를 기본값으로 설정하고 특정 포드 정의를 재정의할 수 있기를 원할 것입니다.

cc @sosiouxme @smarterclayton @liggitt @jwhonce @jcantrill @bparees @jwforres

컨테이너별로(사용 사례) 이를 활용하는 방법을 설명할 수 있습니까? 우리는 전통적으로 런타임 전반에 걸쳐 깔끔하게 추상화될 수 없는 한 Docker 특정 옵션을 컨테이너에 직접 노출하지 않습니다. 이것을 어떻게 사용하고 싶은지 알면 그것을 정당화하는 데 도움이 될 것입니다.

목록이 확장될 수 있다고 생각하지만 도커 로그는 여전히 json-file 및 journald 드라이버만 지원합니다.

아마도 사용자가 실제로 원하는 것은 로깅 드라이버 세부 정보에 노출되는 것이 아니라 정의된 로그 쓰기 끝점을 선택하는 것입니다.

@ncdc @smarterclayton 둘 다 동의합니다. 내부 사용 사례를 재고한 결과

1. 우리의 주요 요구 사항은 노드를 보호하는 것입니다. 로그를 로그 서버로 보내지만 실패하면 도커 내부 로그에 대체 로그를 남깁니다. 이러한 경우 노드 포화를 방지하려면 도커 로그에 대한 클러스터 전체 동작이 필요합니다.
2. @smarterclayton이 제안한 것처럼 pod/Rc 정의에서 특정 도커 옵션을 노출하는 것은 좋은 생각이 아닙니다. 우리는 또한 가능한 경우 높은 수준의 로그 동작을 정의할 수 있는 추상화에 동의합니다.
3. 또 다른 옵션은 이러한 로그 동작을 처리하기 위해 kubelet 구성 파일 및 코드를 변경하는 것입니다.

이것을 기본값으로 만들기 위해 솔트 템플릿을 변경하면 안 됩니다.
끔찍하게 어렵습니다. 그것은 정말로 적절한 데몬 구성입니다(그리고
다음을 통해 fluentd를 통해 로그 집계에 대한 변경 사항을 처리합니다.
다른 소스 선택)

2015년 10월 13일 화요일 오전 10:55 Epo Jemba [email protected]
썼다:

@ncdc https://github.com/ncdc @smarterclayton
https://github.com/smarterclayton 두 분 모두 동의합니다.
내부 사용 사례를 재고해 보면

1. 우리의 주요 요구 사항은 노드를 보호하는 것입니다. 우리는 로그를 로그로 보냅니다.
   서버에 실패하면 도커 내부 로그에 폴백을 기록합니다. 등의
   이 경우 노드 포화를 방지하기 위해 클러스터 전반에 걸친 동작이 필요합니다.
   도커 로그
2. pod/Rc 정의에서 특정 도커 옵션을 노출하는 것은
   @smarterclayton https://github.com/smarterclayton 으로 좋은 아이디어
   제안했다. 우리는 또한 높은 정의를 허용하는 추상화에 동의합니다.
   가능한 경우 레벨 로그 동작
3. 또 다른 옵션은 kubelet 구성 파일을 변경하고
   이러한 로그 동작을 처리하는 코드

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -147740136
.

:엄지손가락:

이제 9개의 로깅 드라이버가 있습니다. 이것을 도입하는 것에 대한 합의는 무엇입니까?

+1

모르는 사람이 있을 경우 Docker 데몬( --log-driver )에 대한 플래그를 사용하여 노드별로 기본 로그 드라이버를 정의할 수 있습니다. 제 환경에서는 이런 식으로 드라이버를 journald 했습니다. 정직하게 컨테이너별로 이것을 재정의하는 유스 케이스를 생각하기 위해 고군분투합니다.

대부분의 클러스터링은 로그가 "대역 외"가 되는 것을 원하지 않으므로 이것이 제공하는 기능은 무엇입니까?

또한 운영 측면에서 통제력 상실처럼 보입니다. 현재 기본값을 설정하고 집계할 로깅 스택을 구성합니다.

이것에 +1.
도커 로깅이 처리되는 방식을 제어할 수 없다는 것은 유일한 정상적인 로깅 옵션이 k8과 함께 제공된 도구를 사용하는 것임을 의미하며, 이는 놀라운 한계입니다.

@timothysc는 여기에 우리의 사용 사례입니다. 우리는 로그를 수집하기 위한 자체 logstash 와 함께 많은 기존 서비스가 실행되는 복잡한 동적 인프라(머신 100대)를 보유하고 있습니다. 글쎄, 우리는 이제 우리의 서비스를 하나씩 k8로 옮기려고 하고 있으며 k8에 클러스터링된 컨테이너와 기존 인프라 사이에 로깅을 통합할 수 있는 확실한 방법이 없는 것 같습니다.

K8S는 로그 수집 방법에 대해 매우 독단적입니다. 이것은 단순한 인프라에서 처음부터 시작하는 사람에게 유용할 수 있습니다. 복잡한 인프라에서 작업하고 있는 다른 모든 사람들에게 깊이 파고들고 사용자 지정 로깅 메커니즘을 구현하는 데 신경 쓰지 않는 경우 현재로서는 이를 수행할 방법이 없으며 이는 매우 실망스럽습니다.

바라건대, 의미가 있습니다.

따라서 시나리오에서 로그는 실제로 "응용 프로그램별"이지만 다음을 수행해야 합니다.
기본 호스트가 해당 로그를 지원하는지 확인합니까? 그것이 우리가 걱정하는 것입니다.
여기서 논의 - 클러스터 수준 또는 노드 수준을 수행하지만 수행하는 경우
포드 수준인 경우 스케줄러는 어떤 로그 드라이버가
어디에 존재합니다. 우리는 가능한 한 그것을 피하려고 합니다.

2016년 5월 23일 월요일 오전 10시 50분, Jacopo Nardiello < [email protected]

썼다:

이것에 +1.
도커 로깅이 처리되는 방식을 제어할 수 없다는 것은
정상적인 로깅 옵션은 k8s와 함께 제공되는 도구를 사용하는 것입니다.
놀라운 한계.

@timothysc https://github.com/timothysc 여기 우리의 사용 사례. 우리는
기존의 많은 복잡한 동적 인프라 (~ 100 머신)
로그를 수집하기 위해 자체 logstash를 사용하여 서비스를 실행합니다. 글쎄, 우리는
이제 우리 서비스를 하나씩 k8로, 그리고 그곳에서 나에게 옮기려고 합니다.
우리의 기존
k8에 클러스터링된 인프라 및 컨테이너.

K8S는 로그 수집 방법에 대해 매우 독단적입니다. 이것은 훌륭할 수 있습니다.
단순한 인프라에서 처음부터 시작하는 사람을 위한 것입니다. 을위한
복잡한 인프라에서 작업하는 다른 모든 사람들은
자세히 살펴보고 사용자 정의 로깅 메커니즘을 구현하려면
현재로서는 매우 실망스러운 방법입니다.

바라건대, 의미가 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

@smarterclayton 귀하의 우려 사항을 이해하며 잘 배치되어 있습니다. 전체 클러스터가 포드 수준 로깅의 존재를 인식해야 하는지 확실하지 않습니다. 우리가 해야 할 일은 포드 stdout/stderr을 어딘가에 기록하는 옵션을 제공하는 것입니다(현재 포드 이름을 기반으로 하는 파일?) 사용자 지정 솔루션을 구현하려는 사람은 누구나 콘텐츠를 얻을 수 있는 영구적인 위치를 갖게 됩니다. 이것은 logrotation이 사소하지 않기 때문에 거대한 챕터를 엽니다.

이것은 내 2센트에 불과하지만 실제 복잡한 시나리오가 기존 로깅 인프라를 포기하는 척 할 수 없습니다.

애플리케이션별로 사용자 정의 로그 옵션을 지정하고 있습니까? 얼마나 다른
클러스터당 로그 옵션 세트가 있습니까? 작은 세트가 있는 경우
config에서 옵션은 다음과 같은 포드에서 주석을 지원하는 것입니다.
많은 "표준 로그
options". 즉, kubelet 시작 시간에 "로그 모드 X"를 정의합니다(이는
사용자 지정 로그 옵션 및 드라이버), 포드는 "
pod.alpha.kubernetes.io/log.mode=X".

또 다른 옵션은 배포자가
시작하기 직전에 컨테이너 정의를 변경할 수 있는 기회
컨테이너. 오늘은 직렬화해야 하기 때문에 더 어렵습니다.
docker def를 중간 형식으로 만들고 실행한 다음 실행합니다.
다시 말하지만 앞으로는 더 쉬울 수 있습니다.

마지막으로 컨테이너 인터페이스에 키 값 쌍을 노출할 수 있습니다.
컨테이너 엔진에 직접 전달되며
그리고 PodSecurityPolicy가 이러한 옵션을 규제할 수 있는지 확인합니다. 그럴 것이다
발신자를 위한 탈출구 역할을 하지만,
릴리스 간에 계속 작동하도록 보장합니다.

2016년 5월 26일 목요일 오전 5:34 Jacopo Nardiello [email protected]
썼다:

@smarterclayton https://github.com/smarterclayton 이해합니다
당신의 관심사와 그것들은 잘 배치되어 있습니다. 전체 클러스터인지 확실하지 않습니다.
포드 수준 로깅의 존재를 인식해야 합니다.
해야 할 일은 pod stdout/stderr을 어딘가에 기록하는 옵션을 제공하는 것입니다(파일
현재 포드 이름을 기반으로?)
사용자 지정 솔루션에는 콘텐츠를 가져올 위치가 유지됩니다.
이것은 logrotation이 사소하지 않기 때문에 거대한 챕터를 엽니다.

이것은 내 2센트에 불과하지만 실제 복잡한 척 할 수는 없습니다.
시나리오는 기존 로깅 인프라를 포기합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

@smarterclayton 보셨나요 https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

고맙지 만 사양 할게. 거기에 토론을 이동합니다.

2016년 5월 26일 목요일 오전 11시 23분, Andy Goldstein 알림 @github.com
썼다:

@smarterclayton https://github.com/smarterclayton 보셨나요 #24677
(논평)
https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221903781

안녕하세요,
이것이 쿠버네티스에서 고려해야 할 중요한 기능이라고 생각합니다.
Docker의 로그 드라이버를 사용하면 몇 가지 사소한 문제를 해결할 수 있습니다.

디스크에 로깅하는 것은 반패턴이라고 말하고 싶습니다. 로그는 본질적으로 "상태"이며 디스크에 저장하지 않는 것이 좋습니다. 로그를 컨테이너에서 저장소로 직접 전달하면 많은 문제가 해결됩니다.

로그 드라이버를 설정하면 kubectl logs 명령이 더 이상 아무 것도 표시할 수 없습니다.
이 기능은 "있으면 좋은" 기능이지만 다른 소스에서 로그를 사용할 수 있는 경우에는 이 기능이 필요하지 않습니다.

Docker에는 이미 google 클라우드(gcplogs) 및 Amazon(awslogs)용 로그 드라이버가 있습니다. Docker 데몬 자체에서 설정할 수는 있지만 많은 단점이 있습니다. 두 가지 도커 옵션을 설정할 수 있습니다.

--log-driver= 컨테이너용 로깅 드라이버
--log-opt=[] 로그 드라이버 옵션

레이블(gcplogs의 경우) 또는 awslogs-group(awslogs의 경우)을 함께 보낼 수 있습니다.
포드에 특정합니다. 그러면 다른 쪽 끝에 있는 로그를 쉽게 찾을 수 있습니다.

사람들이 kubernetes에서 로그를 처리하는 방법에 대해 읽었습니다. 많은 사람들이 로그를 중앙 시스템으로 전달하는 정교한 스크레이퍼를 설정하는 것 같습니다. 로그 드라이버를 설정할 수 있으므로 필요하지 않습니다. 더 흥미로운 작업을 수행할 시간을 확보할 수 있습니다. :)

또한 저를 포함한 일부 사람들은 호스트에서 logrotate를 설정하는 대신 JSON 로깅 드라이버(docker에 기본)에서 '--log-opt max-size' 옵션을 통해 도커 로그 회전을 수행하기를 원한다고 덧붙일 수 있습니다. 따라서 '--log-opt' 옵션만 노출해도 크게 감사하겠습니다.

컨테이너 구성 LogConfig를 생성할 때 k8을 수정했습니다.

+1
중앙 집중식 로그 수집을 위해 도커 로그 드라이버를 사용하는 것은 로그 파일에 대한 심볼릭 링크를 생성하고, 특별한 fluentd 컨테이너에 마운트하고, 로그를 추적하고, 로그 회전을 관리하는 것보다 훨씬 간단해 보입니다.

컨테이너 구성별 사용 사례: 배포한 컨테이너에 대해 다른 곳에 또는 다르게 기록하고 싶고 Kubernetes를 실행하는 데 필요한 표준 컨테이너에 대한 로그 드라이버는 신경 쓰지 않습니다(또는 변경하고 싶지 않습니다).

거기 당신이 간다. 이런 일이 일어나게 해주세요.

또 다른 아이디어는 모든 컨테이너가 여전히 동일한 엔드포인트로 로그를 전달하지만 로그 서버의 대해 최소한 다른 필드 값을 설정할 수 있다는 것 입니다.

Kubernetes에서 생성한 도커 컨테이너에 사용자 지정 레이블이 지정되도록 할 수 있다면 이는 gelf 도커 드라이버에서 작동합니다. 의미: 일부 Pod 필드는 도커 컨테이너 레이블로 전달될 수 있습니다. (아마도 이것은 이미 가능하지만 그것을 달성하는 방법을 모르겠습니다).

Kubernetes가 없는 예, docker 데몬 및 gelf 드라이버만 있습니다. --log-driver=gelf --log-opt labels=env,label2 도커 데몬을 구성하고 도커 컨테이너를 만듭니다.

docker run -dti --label env=testing --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

및 다른 도커 컨테이너:

docker run -dti --label env=production --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

이렇게 하면 Graylog에서 env=production 와 env=testing 컨테이너를 구별할 수 있습니다.

현재 나는 이러한 도커 데몬 옵션을 사용합니다.

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

@xmik , 그것이 기존 기능인지 또는 이에 관한 귀하의 제안인지 확인하는 것

현재 나는 이러한 도커 데몬 옵션을 사용합니다.

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

내가 현재 사용하는 도커 데몬 옵션은 이미 작동합니다. Kubernetes는 이미 각 도커 컨테이너에 대해 일부 레이블을 설정합니다. 예를 들어 kube-apiserver 컨테이너에서 docker inspect 를 실행할 때:

 "Labels": {
   "io.kubernetes.container.hash": "4959a3f5",
   "io.kubernetes.container.name": "kube-apiserver",
   "io.kubernetes.container.ports": "[{\"name\":\"https\",\"hostPort\":6443,\"containerPort\":6443,\"protocol\":\"TCP\"},{\"name\":\"local\",\"hostPort\":8080,\"containerPort\":8080,\"protocol\":\"TCP\"}]",
   "io.kubernetes.container.restartCount": "1",
   "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
   "io.kubernetes.pod.name": "kube-apiserver-k8s-production-master-1",
   "io.kubernetes.pod.namespace": "kube-system",
   "io.kubernetes.pod.terminationGracePeriod": "30",
   "io.kubernetes.pod.uid": "a47396d9dae12c81350569f56aea562e"
}

따라서 해당 도커 데몬 옵션이 작동합니다.

그러나 이제는 Kubernetes가 Pod 사양을 기반으로 도커 컨테이너에 사용자 지정 레이블을 설정하도록 하는 것은 불가능하다고 생각합니다. 예를 들어 --log-driver=gelf --log-opt labels=env,label2 는 작동하지 않습니다.

이 전면에 소식이 있습니까? 레이블을 지정한 다음 --log-opt labels<> 이 있으면 꽤 좋습니다!

@portante @jcantrill 우리가 논의했기 때문에 여기에 캡처하기 위해 이것이 유용할 수 있다고 생각한 사용 사례는 다음과 같습니다.

로그 기록 팟(Pod)이 오류를 만나 기록하기 시작하면 해당 오류를 수집하는 인프라가 오류를 포착하여 다시 기록 메커니즘에 피드백하여 더 많은 오류를 발생시키고 기록합니다.

이 피드백 루프는 필터링 메커니즘을 사용하여 피할 수 있지만 약간 취약합니다. 다른 로깅 드라이버를 사용하여 파일에 기록하고 회전 옵션을 갖는 것이 좋은 솔루션인 것 같습니다.

내 2센트.

k8 내부 로깅에 대한 현재 솔루션은 (AFAIK):

• 어딘가에 로그를 보내는 사이드카 컨테이너
• 모든 로그를 어딘가에 보내는 복제 컨트롤러
• 어딘가에 로그를 보내는 컨테이너 자체

사이드카 컨테이너는 나에게 과한 것 같습니다. 복제 컨트롤러 전략은 좋은 것처럼 보이지만 모든 배포의 컨테이너 로그를 혼합하고 일부 사용자는 이제 이를 원할 수 있으며 대신 각 앱을 다른 항목에 기록할 수 있습니다. 이 경우 마지막 옵션이 IMHO에서 가장 잘 작동하지만 모든 컨테이너에 복제되는 많은 코드를 생성합니다(예: 설치 및 설정 logentries 데몬).

log-driver 플래그에 액세스할 수 있다면 이 모든 것이 훨씬 쉬울 것이므로 각 배포는 도커 기본 기능을 사용하여 로깅 방법을 정의합니다.

구현을 시도할 수 있지만 kubernetes 코드베이스에 익숙하지 않기 때문에 도움이 필요할 것입니다.

멀티 테넌시가 더 중요해지면 제대로 해결하기가 더 어려워질 것입니다.

각 네임스페이스는 서로 다른 테넌트일 수 있으므로 각 네임스페이스의 로그가 반드시 집계되어야 하는 것은 아니지만 테넌트 지정 위치로 보낼 수는 있습니다.

이 작업을 수행하는 몇 가지 방법을 생각할 수 있습니다.

1. 새로운 볼륨 유형인 container-logs를 만듭니다. 이를 통해 특정 네임스페이스에서 시작한 데몬셋이 자체 컨테이너의 로그에만 액세스할 수 있습니다. 그런 다음 선택한 저장소 데몬에 대해 선택한 로그 전달자와 함께 로그를 보낼 수 있습니다.
2. fluentd-bit와 같은 로그 전달자 중 하나(또는 그 이상)를 수정하여 포드가 있는 네임스페이스를 읽고 각 포드의 로그를 해당 네임스페이스에서 서비스로 실행 중인 추가 로그 전달자로 리디렉션합니다. 유창한 것과 같은. 이렇게 하면 네임스페이스가 지원하려는 로그 백엔드에 푸시하도록 자체 로그 전달자를 구성할 수 있습니다.

@caarlos0 @kfox1111 요점에 동의합니다. 이것은 계측, 스토리지, 노드 및 더 많은 팀의 조정이 필요하기 때문에 복잡한 주제입니다. 전체 로깅 아키텍처에 대한 제안을 먼저 배치한 다음 이 일관된 보기로 변경된 사항에 대해 논의하는 것이 좋습니다. 나는 이 제안이 한 달 정도 후에 나타나서 질서를 잡고 언급된 모든 문제를 파악하기를 기대합니다.

@crassirostris 제가 이해했는지 잘 모르겠습니다. log-driver 등만 허용하면 스토리지 또는 그 중 어떤 것도 처리할 필요가 없겠죠 ?

도커는 컨테이너 기반으로 설정된 로그 드라이버에 STDOUT을 보내는 것뿐입니까? 우리는 일종의 책임을 컨테이너로 전달합니다... 저에게는 아주 간단한 해결책처럼 보입니다. 그러나 제가 말했듯이, 저는 코드베이스를 모르기 때문에 아마도 제가 완전히 틀렸을 수도 있습니다...

문제는 docker의 로그 드라이버가 나중에 로그를 실제로 유용하게 사용하는 k8s 메타데이터를 추가하지 않는다는 것입니다. :/

@kfox1111 흠, 말이 되네요...

그러나 사용자가 kubernetes 로그가 아닌 "응용 프로그램" 로그만 원하고 docker 로그가 아닌 컨테이너 로그 내에서 실행 중인 앱만 원하면 어떻게 될까요?

이 경우 log-driver 가 작동하는 것 같습니다 ...

@caarlos0 몇 가지 의미가 있을 수 있습니다. 예를 들어 kubelet은 서버 kubectl 로그에 대한 로깅 형식에 대해 몇 가지 가정을 합니다.

그러나 모든 것을 제쳐두고 log-driver 자체는 Docker 전용이며 다른 런타임에서는 작동하지 않을 수 있습니다. 이것이 API에 포함하지 않는 주된 이유입니다.

@crassirostris 말이 되네요...

이 기능은 추가되지 않을 것이므로(문제에 설명된 대로) 이 문제를 닫아야 합니까(또는 편집하거나 무엇이든)?

@caarlos0 그러나 우리는 확실히 로깅 설정을 더 유연하고 투명하게 만들고 싶습니다. 귀하의 피드백은 제안에 감사하겠습니다!

컨테이너의 stdout 로깅은 현재 Kubernetes 내에서 대역 외에서 처리됩니다. 우리는 현재 로깅을 처리하기 위해 비 Kubernetes 솔루션에 의존하고 있으며, 대역 외 로깅에 액세스하기 위해 Kubernetes를 탈옥하는 권한 있는 컨테이너에 의존하고 있습니다. 컨테이너 런타임 로깅은 런타임(docker, rkt, Windows)마다 다르므로 Docker --log-driver와 같은 것을 선택하면 미래의 짐이 생깁니다.

로그 스트림을 대역 내로 다시 가져오려면 kubelet이 필요하다고 제안합니다. 각 컨테이너에서 stdout 행을 수집하는 최소 JSON 또는 XML 로그 형식을 정의하거나 선택하고 최소 클러스터+네임스페이스+포드+컨테이너 메타데이터를 추가하여 로그 소스가 Kubernetes 공간 내에서 식별되도록 하고 스트림을 Kubernetes Service+로 보냅니다. 포트. 사용자는 원하는 로그 소비 서비스를 자유롭게 제공할 수 있습니다. 아마도 Kubernetes는 'kubectl logs' 지원을 구현하는 하나의 참조/기본 서비스를 제공할 것입니다.

로깅 소비 서비스를 지정하지 않으면 로그가 삭제되고 디스크에 전혀 도달하지 않습니다 . 다른 곳에서 로그를 스트리밍하거나 영구 저장소에 쓰고 회전하는 것은 모두 서비스의 책임/결정입니다.

kubelet 컨테이너 런타임 래퍼는 각 컨테이너 런타임에서 stdout을 추출하기 위해 최소한의 작업을 수행하고 k8 자체 호스팅 서비스가 소비 및 처리할 수 있도록 대역 내로 다시 가져옵니다.

Deployment 또는 Pod의 컨테이너 사양은 선택적으로 stdout 로깅을 위한 대상 서비스 및 포트를 지정합니다. 클러스터+네임스페이스+포드+컨테이너에 대한 k8s 메타데이터를 추가하는 것은 선택 사항입니다(따라서 원시/무손 또는 메타데이터 선택). 사용자는 자유롭게 모든 로그를 한 곳으로 집계하거나 테넌트, 네임스페이스 또는 애플리케이션별로 집계할 수 있습니다.

지금 가장 가까운 것은 'kubectl logs -f'를 사용하여 API 서버를 통해 각 컨테이너에 대한 컨테이너 로그를 스트리밍하는 서비스를 실행하는 것입니다. 그다지 효율적이거나 확장 가능하지 않은 것 같습니다. 이 제안은 컨테이너 런타임 래퍼에서 서비스 또는 파드로 직접 스티밍을 더 효율적으로 허용하고 동일한 노드에서 배포 또는 Daemonset 파드를 로깅하고 컨테이너가 로그를 생성하는 것을 선호하는 것과 같은 최적화를 제공합니다.

나는 Kubernetes 공간 내에서 생성하기 위해 사용하는 자체 호스팅, 동종 또는 이종 로깅 솔루션에 대해 컨테이너 런타임 로그를 효율적으로 대역 내로 가져오기 위해 최소한의 조치를 취해야 한다고 제안합니다.

사람들은 어떻게 생각합니까?

@whereisaaron 로깅 생태계에 대한 모든 세부 정보가 한 곳에 있지 않을 때 지금은 이 토론을 하고 싶지 않습니다.

예를 들어 로그 흐름을 방해하는 네트워크 및 시스템 문제를 보았지만 아직 논의하고 싶지 않습니다. 제안이 준비되면 나중에 논의하는 것이 어떻습니까? 그것이 당신에게 합리적으로 보입니까?

확실히 @crassirostris. 제안서를 확인할 준비가 되면 여기에서 알려주십시오.

/ 시그 확장성

모두 있지만 --log-driver 및 --log-opt 도커 데몬에 대한 옵션입니다하지가 K8S 포드 사양에 대한 그들을 지정하는 데 좋은 것, 기능을 K8S :

1. 단일 노드 수준 로그 드라이버가 아닌 포드별 로그 드라이버
2. 동일한 노드에 있는 다양한 유형의 앱별 로그 드라이버(fluentd, syslog, journald, splunk)
3. --log-opt 를 설정하여 포드에 대한 로그 회전을 구성합니다.
4. 포드당 --log-opt 설정이 아닌 단일 노드 수준 --log-opt

AFAIK, 위의 어느 것도 오늘날 k8s 포드 사양의 포드 수준에서 설정할 수 없습니다.

@vhosakot 위의 어느 것도 Kubernetes 개념이 아니기 때문에 Kubernetes의 모든 수준에서 설정할 수 없습니다.

@crassirostris 정확히! :)

Docker가 Pod 수준/컨테이너 수준에서 수행하는 모든 작업을 k8s가 수행하면 사용자가 사용하기 쉽지 않을까요? 사용자가 포드 수준/컨테이너 수준 항목에 대해 Docker를 전혀 사용하지 않는 이유는 무엇입니까?

그리고 Docker 팬이 아닌 k8s 애호가도 같은 질문을 할 수 있습니다.

@vhosakot Point는 --log-opt 는 Docker에만 존재한다는 것입니다. K8 수준에서 이러한 옵션을 만들면 의도적으로 추상화가 누출됩니다. 나는 이것이 우리가 가고자 하는 방식이 아니라고 생각합니다. 옵션이 있는 경우 모든 컨테이너 런타임에서 지원해야 하며 이상적으로는 CRI의 일부여야 합니다.

나는 그러한 옵션이 없을 것이라고 말하는 것이 아니라 Docker에 대한 직접적인 경로가 없을 것이라고 말하는 것입니다.

@crassirostris 사실, k8이 Docker 특정이 아닌 포드 수준/컨테이너 수준에서 CRI가 수행/허용하는 작업을 수행해야 하는지 여부에 따라 달라집니다.

네, 절대적으로 맞습니다.

비록 내가 이 토론에 늦었고 이 기능이 구현되는 것을 보는 데 관심이 있지만, 예쁜 디자인을 갖는 것과 제정신이고 균일한 로깅 솔루션을 설정하는 직접적인 방법을 갖는 것 사이에는 절충점이 있다고 주장하고 싶습니다. 클러스터에 대한. 예, 이 기능을 구현하면 docker internal 가 노출됩니다. 이는 큰 문제가 아닙니다. 하지만 동시에 대부분의 K8S 사용자가 기본 컨테이너 기술로 docker를 사용하고 docker는 매우 포괄적인 목록과 함께 제공된다는 점에 상당한 돈을 걸 수 있습니다. 로그 드라이버의.

@gabriel-tincu 현재 원본 FR이 문제가 될 가치가 있는지 확신하지 못합니다.

docker는 매우 포괄적인 로그 드라이버 목록과 함께 제공됩니다.

K8 배포 단계에서 Docker 수준에서 로깅을 설정하고 이 정보를 K8에 유출하지 않고 이러한 로그 드라이버를 사용할 수 있습니다. 오늘 할 수없는 유일한 것은 컨테이너 / 포드 당 옵션을 설정하는 것입니다 (실제로는 전용 노드로 설정하고 노드 선택기를 사용할 수 있음). 그러나 그것이 큰 제한인지 확실하지 않습니다.

@crassirostris 환경을 설정하기 __전에__ 설정할 수 있다는 데 동의하지만 환경이 이미 설정된 후에 도커 로그 드라이버를 적극적으로 업데이트하는 방법이 있으면 현재로서는 피할 수 있습니다.

@gabriel-tincu @vhosakot >=1.5의 '옛날'에 k8과 Docker 사이에 존재하던 직접 인터페이스는 더 이상 사용되지 않으며 이제 코드가 완전히 제거되었다고 생각합니다. kubelet과 Docker(또는 rkt, cri-o, runc, lxd와 같은 다른 것들)와 같은 런타임 사이의 모든 것은 CRI를 거칩니다. 현재 많은 컨테이너 런타임이 있으며 Docker 자체는 더 이상 사용되지 않으며 cri-containerd + containerd 를 위해 곧 제거될 것입니다.

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

@crassirostris 제안에 대한 어떤 움직임도 밴드 내 컨테이너 로깅의 가능성이 있을 수 있습니까?

CRI 컨테이너 로그는 파일 기반(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md)이며 로그 경로는 명시적으로 정의됩니다.

/var/log/pods/PodUID/ContainerName/RestartCount.log

대부분의 도커 로깅 드라이버 https://docs.docker.com/config/containers/logging/configure/#supported -logging-drivers에서 클러스터 환경에서 가장 중요한 것은 클러스터에 컨테이너 로그인을 수집하는 드라이버라고 생각합니다. splunk , awslogs , gcplogs 등과 같은 로깅 관리 시스템

CRI의 경우 "도커 로그 드라이버"를 사용해서는 안 됩니다. 사람들은 데몬셋을 실행하여 CRI 컨테이너 로그 디렉토리에서 원하는 곳으로 컨테이너 로그를 수집할 수 있습니다. 그들은 fluentd를 사용하거나 스스로 데몬셋을 작성할 수도 있습니다.

더 많은 메타데이터가 필요한 경우 메타데이터 파일을 삭제하거나 파일 경로를 확장하거나 daemonset이 apiserver에서 메타데이터를 가져오도록 할 수 있습니다. 이에 대한 논의가 진행 중입니다. https://github.com/kubernetes/kubernetes/issues/58638

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

30일 동안 사용하지 않으면 오래된 문제가 썩습니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.
썩은 문제는 추가로 30일 동안 활동이 없으면 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/라이프사이클 썩은
/remove-lifecycle 부실

/remove-lifecycle 썩음

이것에 대한 업데이트가 있습니까? 그렇다면 Docker 컨테이너로 k8을 실행하는 사람이 AWS CloudWatch와 같은 일부 백엔드에 대한 로깅을 어떻게 해결했습니까?

@bryan831 fluentd 또는 이와 유사한 것을 사용하여 k8s 컨테이너 로그 파일을 수집하고 원하는 백엔드, CloudWatch, StackDriver, Elastisearch 등으로 집계하는 것이 일반적입니다.

예를 들어 fluentd+CloudWatch , fluentd+Elastisearch , fluent-bit->fluentd->your choice , Datadog 및 다른 조합에 대한 기성품 Helm 차트가 있습니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

Docker --log-opt 옵션을 사용자 정의할 수 있으면 좋을 것입니다. 제 경우에는 '--log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"'와 같은 태그를 사용하여 ImageName을 로그에 내보내고 싶습니다. 어떤 컨테이너 버전에서 로그가 나오는지 알 수 있습니다. (참고 : https://docs.docker.com/config/containers/logging/log_tags/)

/remove-lifecycle 부실

@pmahalwar-intertrust 도커 데몬에 동일한 --log-opt를 전달할 수 있으며 이는 모든 컨테이너에 영향을 미칩니다...

@pmahalwar-intertrust kubernetes가 containerd 에서 수집한 로그에는 이미 광범위한 메타데이터가 포함되어 있으며 컨테이너에 적용한 모든 레이블이 포함되어 있습니다. fluentd 수집하면 아래 로그 항목과 같이 모든 메타데이터를 얻을 수 있습니다.

{
    "log": " - [] - - [25/Oct/2018:06:29:48 +0000] \"GET /nginx_status/format/json HTTP/1.1\" 200 9250 \"-\" \"Go-http-client/1.1\" 118 0.000 [internal] - - - - 5eb73997a372badcb4e3d993ceb44cd9\n",
    "stream": "stdout",
    "docker": {
        "container_id": "3657e1d9a86e629d0dccefec0c3c7624eaf0c4a11f60f53c5045ec0839c37f06"
    },
    "kubernetes": {
        "container_name": "nginx-ingress-controller",
        "namespace_name": "ingress",
        "pod_name": "nginx-ingress-dev-controller-69c644f7f5-vs8vw",
        "pod_id": "53514ad6-d0f4-11e8-a04c-02c433fc5820",
        "labels": {
            "app": "nginx-ingress",
            "component": "controller",
            "pod-template-hash": "2572009391",
            "release": "nginx-ingress-dev"
        },
        "host": "ip-172-29-21-204.us-east-2.compute.internal",
        "master_url": "https://10.3.0.1:443/api",
        "namespace_id": "e262510b-180a-11e8-b763-0a0386e3402c"
    },
    "kubehost": "ip-172-29-21-204.us-east-2.compute.internal"
}

이러한 기능을 지원할 계획은 아직 없나요?
--log-driver= 컨테이너용 로깅 드라이버
--log-opt=[] 로그 드라이버 옵션

안녕하세요 @lifubang 누구의 계획에 대해 말할 수 없지만 이러한 기능을 지원하는 데몬인 dockerd 는 더 이상 Kubernetes의 일부가 아닙니다(위에 대한 설명 참조).

원한다면 여전히 선택적으로 설치할 수 있으므로 이전 dockerd 로그 드라이버를 사용하기 위해 그렇게 할 수 있습니다. 해당 옵션은 여기에서 설명합니다.
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

그러나 fluentd 와 같은 전용 로깅 서비스를 사용하는 것이 좋습니다. 클러스터 또는 Pod별로 사이드카로 전역적으로 배포할 수 있습니다. 여기에서는 Kubernetes 로그인에 대해 설명합니다.
https://kubernetes.io/docs/concepts/cluster-administration/logging/

@whereisaaron에 의해 설명 된대로 내가보기 엔 Fluentd에 추천

이 기능 요청이 작업 중인 한... kubernetes 아키텍처 로드맵에는 kubernetes의 "일부"가 아닌 항목의 "생태계" 섹션 아래에 로깅이 있으므로 이러한 기능이 기본적으로 지원될지는 의문입니다.
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

k8을 실행할 때 인생을 망칠 수 있는 몇 가지 버그가 있으므로 fluentd를 사용하지 않는 것이 좋습니다.

in_tail은 도커가 https://github.com/fluent/fluentd/issues/1680 컨테이너를 제거하는 것을 방지

in_tail은 시작 단계에서 추적되지 않은 파일 위치를 제거합니다. 이는 pos_file의 내용이 다시 시작될 때까지 증가하고 동적 경로 설정으로 많은 파일을 처리할 때 이를 통해 스캔하는 많은 CPU를 먹을 수 있음을 의미합니다.
https://github.com/fluent/fluentd/issues/1126.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

@roff님의 경험에 감사드립니다. fluent/fluentd#1680은 k8s 1.5에 대한 문제였으며 그 당시에는 'in_tail'을 사용하지 않았습니다. k8이 containerd 로깅으로 이동했기 때문에 여전히 문제가 아닌 것 같습니까? fluent/fluentd#1126에서 감지할 수 있는 영향을 보지 못했습니다.

fluentd 에 대해 추천하셨습니다. 대신 무엇을 추천하시겠습니까? k8s 메타데이터를 사용한 로그 집계에 fluentd 대신 개인적으로 무엇을 사용합니까?

30일 동안 사용하지 않으면 오래된 문제가 썩습니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.
썩은 문제는 추가로 30일 동안 활동이 없으면 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/라이프사이클 썩은

썩은 문제는 30일 동안 활동이 없으면 닫힙니다.
/reopen 문제를 다시 엽니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/닫다

@fejta-bot: 이 문제를 종료합니다.

닫히지 말았어야 했어, 그렇지?
기능 요청은 포드당 log-opts를 설정하려고 할 때 여전히 의미가 있습니다(데몬에서 설정하거나 logrotate를 사용하지 않고)...

k8 내부에서 도커별 구성 옵션을 지원하는 것은 좋은 생각이 아니라고 확신합니다. 이전에 언급했듯이 fluentd daemonset 또는 fluenbit 사이드 카가 현재 옵션입니다. 사이드카가 훨씬 더 안전하기 때문에 저는 사이드카를 선호합니다.

@whereisaaron K8s@containerd에 대한 로깅 솔루션을

--log-driver , --log-opt 는 여전히 지원되지 않습니까?
단일 포드에서 Splunk로 로그를 전달하는 방법을 찾고 있습니다. 어떤 아이디어?

단일 포드의 경우 @sariel1212 splunk 포워딩 에이전트인 사이드 카 컨테이너를 포드에 포함하는 것이 좋습니다. 포드의 모든 컨테이너 간에 emptydir 볼륨을 공유하고 애플리케이션 컨테이너가 공유 emptydir에 로그를 쓰도록 할 수 있습니다. 그런 다음 splunk 포워더 컨테이너가 해당 볼륨에서 읽고 전달하도록 합니다.

전체 클러스터 @sariel1212 에 대해 Splunk에 수집하려는 경우 수집할 Splunk HEC fluentd 플러그인 을 사용하여 fluentd 를 배포 하는 @coffeepac 의 경우 공유 emptydir이 있는 사이드카 제안은 좋은 접근 방식입니다.

이 시간이 지난 후에도 클러스터 소유자가 Docker 로그 드라이버를 사용할 수 있는 방법이 아직 없다는 것은 매우 끔찍합니다.

Docker-Compose(내 K8s 클러스터 시뮬레이션)를 사용하여 매우 빠르게 설정하여 모든 stdout/err을 내 로그 집계 서비스로 파이프할 수 있었습니다.

Kubenetes에서 이것을 하려고 하십니까? 이 스레드에서 모든 마이크로 서비스에 대한 코드를 보강해야 할 것 같습니다! 안좋다.

@ashleydavis 님 , dockerd 는 Kubernetes에서 더 이상 사용되지 않으므로 더 이상 Kubernetes의 일부가 아닌 항목에 대한 지원을 도입하는 것은 의미가 없습니다. Kubernetes 외에도 여전히 설치할 수 있습니다. 배경은 다음과 같습니다.
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Kubernetes는 기본적으로 모든 컨테이너에 대한 stdout/stderr 로그를 자동으로 스트리밍합니다. 각 노드에 하나의 컨테이너( DaemonSet )를 배포하기만 하면 해당 로그 스트림을 수집하고 선택한 집계 서비스로 보낼 수 있습니다. 정말 쉬워요.

https://docs.fluentd.org/container-deployment/kubernetes

여기에 백 집계 백엔드를 위한 기성품 fluentd +백엔드 컨테이너 이미지와 샘플 구성이 많이 있습니다.

https://github.com/fluent/fluentd-kubernetes-daemonset

DataDog를 사용하는 경우 대신 설치할 자체 에이전트가 있거나 fluentd .

https://docs.datadoghq.com/integrations/kubernetes/

일반적으로 docker 는 로깅 및 로그 플러그인, 스웜, 런타임 도구, 빌드 도구, 네트워킹 및 파일 시스템 마운트 등을 모두 하나의 데몬 프로세스에서 kitchen sink docker 하는 경향이 있습니다. Kubernetes는 일반적으로 각각 하나의 작업을 수행하고 API를 통해 통신하는 느슨하게 결합된 컨테이너/프로세스를 선호합니다. 그래서 익숙해지기에는 조금 다른 스타일입니다.

자세한 답변 감사합니다. 나는 확실히 이것에 대해 조사 할 것입니다.

dockerd가 더 이상 사용되지 않는다는 것은 향후 Kubernetes에 Docker 이미지를 배포할 수 없다는 것을 의미합니까?

@ashleydavis 확실히 'Docker' 이미지를 계속 사용할 수 있으며( dockerd 없어도), Kubernetes 노드에 계속해서 dockerd 를 배포할 수 있습니다(예: docker-in-docker에서와 같이). 빌드) 원하는 경우. docker의 핵심 부분을 추출하여 'OCI 컨테이너'와 containerd 런타임으로 표준화하였습니다.

https://www.opencontainers.org/
https://containerd.io/

Docker와 Kubernetes는 이제 이러한 공유 표준을 기반으로 합니다.

https://blog.docker.com/2017/08/what-is-containerd-runtime/
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

덕분에 많이 배우고 있습니다.

방금 Loggy라는 마이크로 서비스를 만들었습니다. 의도는 Docker 로그 드라이버에서 로그를 보낸 다음(웹훅을 통해) Slack으로 전달하는 것이었습니다.

여기에서 코드를 볼 수 있습니다: https://github.com/artlife-solutions/loggy/blob/master/src/index.ts

매우 간단합니다. 로그를 수신하고 HTTP POST를 통해 Slack으로 전달합니다.

내 포드에서 로그를 수집하고 집계할 수 있도록 이를 조정하는 가장 빠른 방법은 무엇입니까?

@ashleydavis 해당 마이크로 서비스가 포함된 컨테이너 이미지를 빌드한 다음

1. 클러스터의 모든 컨테이너가 ( 서비스의 클러스터 DNS 이름을 사용하여) 보낼 수 있는 서비스 와 함께 배포 로 클러스터에 합니다 .

2. 배포에 추가 '사이드카' 컨테이너로 배포 합니다. 동일한 Pod의 컨테이너는 동일한 localhost 대한 비공개 액세스를 공유 하므로 애플리케이션 컨테이너가 localhost:12201 의 마이크로 서비스 컨테이너 사이드카로 보낼 수 있습니다. 또는 동일한 Pod의 컨테이너가 공유 로그 파일 또는 명명된 파이프에 대한 할 수 있습니다 .

이것은 여기에서 주제 에서 벗어나고 모든 사람이 이것을 원하는 것은 아니므로 예를 조사하고 조언을 위해 Slack 채널 을 방문하십시오.

https://github.com/ramitsurana/awesome-kubernetes
https://slack.k8s.io/
https://kubernetes.io/

감사합니다. 기존 서비스를 변경할 필요가 없기를 바랐습니다. 나는 그들의 표준 출력/오류를 캡처하고 싶습니다. 어쨌든 그렇게 하려면?

Docker 로그 드라이버의 약속은 단순성이었습니다. 이 작업을 수행하는 간단한 방법이 있습니까?

물론 @ashleydavis , 클러스터를 배포하고 fluentd 배포 하고 쾅, 완료 😺. 배포하는 모든 애플리케이션에는 선호하는 수집기로 배송되는 stdout/stderr이 있습니다. 👍

K8s 및 로깅에 시간을 투자한 후 명시적인 GELF 구성 없이 멋진 https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html을 살펴보십시오.

내 설정은 로그를 필터링 및 추출하고 Elasticsearch로 파이프하는 Logstash로 파이프하는 Filebeat입니다. Kibana를 사용하여 로그를 보고 데이터를 집계할 수 있습니다.

또한 운영 체제의 기본 syslog 파일에 대한 로깅을 지원하고 싶습니다. 예를 들어 Ubuntu에서 /var/log/syslog 로그를 작성할 수 있으며 이는 기본적으로 logrotate에 의해 관리됩니다.

swarm/compose를 사용하면 다음과 같이 할 수 있습니다.

version: '3.3'
services:
  mysql:
    image: mysql:5.7
    logging:
      driver: syslog
      options:
        tag: mysql

emtpyDir 볼륨을 사용하는 것은 괜찮지만 로그 파일을 회전/자르는 추가 프로세스를 추가하지 않는 한 장기 실행 포드는 볼륨을 채울 위험이 있습니다. OS가 이미 /var/log/syslog의 회전을 처리하고 있을 때 이 추가 복잡성에 동의하지 않습니다.

일부 배포에 사이드카를 사용하는 것이 좋은 아이디어라는 데 동의하지만(일부 배포에 대해 이미 이 작업을 수행하고 있음) 모든 사람의 환경이 다릅니다.

emtpyDir 볼륨을 사용하는 것이 좋습니다.

그것들을 조심하세요. 그것들은 Kubernetes에 의해 관리되고 그들의 수명은 당신에 의해 통제되지 않습니다. 포드가 제거되고 다른 노드로 다시 예약되면 로그가 손실됩니다. 포드를 업데이트하고 해당 uid가 변경되면 이전 볼륨을 사용하지 않고 새 볼륨을 만들고 이전 볼륨을 제거합니다.

@jsirianni 모든 시스템이 syslog를 실행하는 것은 아닙니다. 즉, 주어진 포드의 요구 사항을 충족하기 위해 사용할 수 있는 기능에 대한 노드별 주석이 있어야 합니다. docker compose는 로컬에서만 실행되기 때문에 이러한 가정을 합니다.

@coffeepac 노드에 syslog가 없다고 해서 운영자에게 옵션이 없어야 하는 것은 아닙니다. syslog를 사용하려는 경우 작업자 노드에 syslog가 있는지 확인합니다.

이 기능에 대한 사용 사례가 아직 충분하므로 이 문제를 다시 열어야 한다고 생각합니다.
/다시 열다

@saiyam1814 : 이 문제를

개인적으로 나는 여전히 쿠버네티스가 도커 로그 드라이버나 로깅을 구성하기 위한 다른 간단한 내장 방법을 지원해야 한다고 생각한다.

Kubernetes에서 로깅 설정이 쉽다는 말을 여러 번 들었지만 이제 자체 로깅 집계 시스템을 설정하는 과정을 거치면서 정말 간단하지 않다고 말할 수 있습니다.

Kubernetes용 로그 집계 시스템을 수동으로 실행하는 가장 간단한 방법에 대한 블로그 게시물을 작성했습니다. http://www.the-data-wrangler.com/kubernetes-log-aggregation/

내 블로그 게시물이 다른 사람들이 자신의 전략을 찾는 데 도움이 되기를 바랍니다.

그렇게 어렵지는 않지만 이것이 우리가 있는 곳입니다.

물론 로그 파일을 사용하는 대신 stdout 및 stderr에서 직접 Docker 로그를 사용하는 방법이 필요합니다. 호스트 시스템의 다른 로그에 액세스할 수 있으므로 Docker 경로를 사용하여 파일을 기록하는 데는 몇 가지 보안 문제가 있습니다.

Docker 로그 드라이버를 구현할 수 있습니까? 👍

포드가 고객 제어에 있는 컨테이너 인 어 포드 수준에서 도커 로그 드라이버를 구성하면 gelf 드라이버가 있는 로그를 직접 그레이로그 서비스/포드(고객 제어에도 있음)로 리디렉션할 수 있습니다. ) 다른 즉각적인 서비스( gelf 로그 드라이버를 사용하는 것보다 더 많은 관리 오버헤드 및 더 나쁜 추상화 수준 중단)를 사용하여 호스트의 파일에서 또는 컨테이너 로그 디렉토리에 액세스하는 고객의 포드에서 수집하는 대신 호스트에.

따라서 이 기능이 kubernetes에서 구현되는 것을 보고 싶습니다.

https://github.com/cri-o/cri-o/pull/1605 와 같은 작업을 수행하는 것이 도움이 될 것입니다. 여기서 컨테이너 동작이 어떻게 영향을 미칠 수 없도록 로그 드라이버에서 로그 스트림 해석을 분리합니다. 드라이버가 작동합니다.

썩은 문제는 30일 동안 활동이 없으면 닫힙니다.
/reopen 문제를 다시 엽니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/닫다

@fejta-bot: 이 문제를 종료합니다.

기능은 아직 구현해야 합니다.
/다시 열다

@M0rdecay :

@M0rdecay :

알았어, 이해했어

aws ecs에도 도커 로깅 드라이버를 설정할 수 있는 이 기능이 있습니다.
우리 환경에서는 각 컨테이너 서비스에 대해 고유한 토큰이 있는 별도의 인덱스를 만들었습니다.

"로그 구성": {
"logDriver": "splunk",
"옵션": {
"splunk 형식": "원시",
"splunk-insecureskipverify": "true",
"splunk-token": "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx",
"splunk-url": " https://xxxxx.splunk-heavyforwarderxxx.com ",
"태그": "{{.Name}}/{{.ID}}",
"splunk-verify-connection": "거짓",
"모드": "비차단"
}
}

그러나 k8에서는 이와 같은 것을 찾지 못했습니다. 포드 정의 자체에 있어야 합니다.

옵션은 아직 구현해야 합니다.
/다시 열다

@ejemba : 이 문제를

/ 서명 노드
/ 시그 제거 계측

/remove-sig 확장성

@logicalhan : 해당 레이블이 문제에 설정되지 않았습니다. sig/

어떤 진전이 있습니까?
도커의 gelf 로그 드라이버를 지정하여 외부 logstash에 로그인하도록 포드의 컨테이너를 설정하는 기능을 특별히 찾고 있었습니다. /etc/docker/daemon.json의 모든 컨테이너에 대해 기본적으로 설정하는 것은 오버헤드인 것 같습니다.

썩은 문제는 30일 동안 활동이 없으면 닫힙니다.
/reopen 문제를 다시 엽니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/닫다

@fejta-bot: 이 문제를 종료합니다.

/다시 열다

@andreswebs : 본인이 저작했거나 공동 작업자가 아닌 이상 이슈/PR을 다시 열 수 없습니다.

/다시 열다

@ejemba : 이 문제를

@ejemba : 이 문제는 현재 분류 ​​대기 중입니다.

SIG 또는 하위 프로젝트에서 이것이 관련 문제라고 판단하면 triage/accepted 레이블을 적용하여 이를 수락하고 추가 지침을 제공합니다.

triage/accepted 레이블은 댓글에 /triage accepted 를 작성하여 조직 구성원이 추가할 수 있습니다.

이 기능이 구현되었으면 정말 좋겠습니다. 현재 Rancher 1.x 클러스터에서 k8을 실행하는 Rancher 2.x 클러스터로 워크로드를 마이그레이션하고 있습니다. docker-compose 구성에서 log-driver 및 log-opt 매개변수를 설정하는 배포가 있습니다.

하나의 특정 호스트를 구성하여 gelf 드라이버를 전역적으로 사용하고 포드에 레이블을 지정하고 호스트에 레이블을 지정하도록 구성하고 싶지 않습니다.

CRI-O를 변경하여 두 컨테이너 로그 스트림(stdout / stderr)이 모두 원시 형식으로 수집되고 나중에 원시를 읽을 때 로그 바이트 스트림의 다른 해석을 적용할 수 있도록 지정해야 합니다.

https://github.com/cri-o/cri-o/pull/1605를 참조

썩은 문제는 30일 동안 활동이 없으면 닫힙니다.
/reopen 문제를 다시 엽니다.
/remove-lifecycle rotten 하여 문제를 최신으로 표시합니다.

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/닫다

@fejta-bot: 이 문제를 종료합니다.