Consul on Kubernetes 오류 메시지
Consul on Kubernetes 오류 메시지
이 주제에서는 Consul on Kubernetes와 관련된 잠재적인 오류 메시지에 대한 정보를 제공해요. 이 섹션에 없는 오류 메시지를 받으면 여러 오류 참조 리소스를 확인할 수 있어요.
출처: 문서
본문
이 주제에서는 Consul on Kubernetes와 관련된 잠재적인 오류 메시지에 대한 정보를 제공합니다. 이 섹션에 없는 오류 메시지를 받으면 다음 리소스를 참조하세요.
- Consul error messages
- API gateway error messages
- Consul-Terraform-Sync error messages
- Consul Discuss forum
같은 호스트의 Consul 클라이언트에 연결할 수 없음
pod가 같은 호스트에서 실행 중인 Consul 클라이언트에 연결할 수 없다면 먼저 kubectl get pods로 Consul 클라이언트가 실행 중인지 확인하세요.
$ kubectl get pods --selector="component=client"
NAME READY STATUS RESTARTS AGE
consul-kzws6 1/1 Running 0 58s
여전히 연결할 수 없고 Kubernetes 워커의 Consul 클라이언트에 연결할 때 i/o timeout 또는 connection refused 오류가 보인다면, 컨테이너 네트워킹 인터페이스(CNI)가 hostPort 사용을 지원하지 않는 것일 수 있습니다.
다음 예시 오류 메시지의 IP 10.0.0.10은 Consul 클라이언트 pod가 실행 중인 호스트의 IP를 말합니다.
Put http://10.0.0.10:8500/v1/catalog/register: dial tcp 10.0.0.10:8500: connect: connection refused
Put http://10.0.0.10:8500/v1/agent/service/register: dial tcp 10.0.0.10:8500: connect: connection refused
Get http://10.0.0.10:8500/v1/status/leader: dial tcp 10.0.0.10:8500: i/o timeout
이 문제를 해결하려면 Helm values에서 hostNetwork를 활성화하세요. 호스트 네트워크를 사용하면 CNI가 컨테이너와 호스트 사이의 포트 매핑을 지원할 필요 없이 pod가 호스트의 네트워크 네임스페이스를 사용할 수 있습니다.
client:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
참고
호스트 네트워크 사용은 Consul 클라이언트에게 호스트의 모든 네트워크 트래픽에 불필요한 액세스를 부여하므로 보안상 영향이 있습니다. 사용 중인 CNI에 hostPort 지원 추가를 요청하는 이슈를 제기하고 결국 hostPort로 다시 전환하는 것이 좋습니다.
ACL 인증 메서드 로그인 실패
서비스 메시 pod의 init 컨테이너 로그에서 다음 오류를 보게 되면, pod의 서비스 계정 이름이 Kubernetes Service와 일치하는지 확인하세요.
consul-server-connection-manager: ACL auth method login failed: error="rpc error: code = PermissionDenied desc = Permission denied"
예를 들어 serviceAccountName이 static-server 대신 does-not-match이면 다음 배포는 실패합니다.
apiVersion: v1
kind: Service
metadata:
# This name will be the service name in Consul.
name: static-server
spec:
selector:
app: static-server
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: static-server
spec:
replicas: 1
selector:
matchLabels:
app: static-server
template:
metadata:
name: static-server
labels:
app: static-server
annotations:
'consul.hashicorp.com/connect-inject': 'true'
spec:
containers:
- name: static-server
image: hashicorp/http-echo:latest
args:
- -text="hello world"
- -listen=:8080
ports:
- containerPort: 8080
name: http
serviceAccountName: does-not-match
바인딩되지 않은 PersistentVolumeClaims
Consul 서버 pod가 Pending 상태에 갇혀 있다면 PersistentVolumeClaims(PVC)가 PersistentVolumes(PV)에 바인딩되어 있는지 확인하세요. 바인딩되어 있지 않으면 다음과 유사한 오류가 표시됩니다.
$ kubectl describe pods --namespace consul consul-server-0
Name: consul-server-0
Namespace: consul
##...
Status: Pending
##...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 3m29s (x3 over 13m) default-scheduler 0/3 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.
이 문제를 해결하는 방법은 두 가지입니다. 가장 빠르고 간단한 옵션은 최신 버전의 Helm chart 또는 consul-k8s 도구를 사용해 Consul을 배포하는 것입니다. consul-k8s 도구는 필요한 PV를 자동으로 만들어 줍니다.
최신 버전의 Helm chart 또는 consul-k8s 도구를 사용할 수 없다면 PV 생성을 관장하는 StorageClass 객체를 수동으로 만들고 Consul Helm chart에 지정할 수 있습니다. 예를 들어 다음 YAML을 사용해 AWS EBS 볼륨에 대한 ebs-sc라는 StorageClass를 만들 수 있습니다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
csi.storage.k8s.io/fstype: xfs
type: io1
iopsPerGB: "50"
encrypted: "true"
마지막으로 Consul Helm chart values에 StorageClass를 지정하고 Consul을 Kubernetes에 재배포합니다.
##...
server:
storageClass: "ebs-sc"
##...