Kubernetes 서비스 외부 IP 보류 중
Kubernetes 서비스 외부 IP 보류 중
나는 nginx를 kubernetes에 배치하려고 하는데, kubernetes 버전은 v1.5.2이고, 나는 nginx를 3개의 복제본으로 배치했고, YAML 파일은 아래와 같다,
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: deployment-example
spec:
replicas: 3
revisionHistoryLimit: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.10
ports:
- containerPort: 80
이제 노드의 포트 30062에 포트 80을 노출하려고 합니다. 이를 위해 아래 서비스를 만들었습니다,
kind: Service
apiVersion: v1
metadata:
name: nginx-ils-service
spec:
ports:
- name: http
port: 80
nodePort: 30062
selector:
app: nginx
type: LoadBalancer
이 서비스는 정상적으로 작동하지만 단말기에서도 kubernetes 대시보드뿐만 아니라 보류 중으로 표시됩니다.
사용자 지정 Kubernetes 클러스터를 사용하고 있는 것 같습니다(또는 유사한 것을 사용). 이 경우 로드 밸런서가 통합되어 있지 않습니다(AWS나 Google Cloud와 달리). 이 기본 설정에서는 또는 입력 컨트롤러만 사용할 수 있습니다.
를 사용하여 포드에 매핑할 도메인 이름을 설정할 수 있습니다. 입력 컨트롤러를 사용하는 경우 서비스에 유형을 지정할 필요가 없습니다.
에서 서비스에 액세스하려면 다음 명령을 실행해야 합니다:
minikube service [-n NAMESPACE] [--url] NAME
자세한 내용은 여기에서 확인하십시오:
GCE 또는 EKS(사용한)를 사용하지 않는 경우 서비스 YAML에 규격을 추가할 수 있습니다. 다음과 같은 노드의 기본 인터페이스와 연결된 IP를 사용할 수 있습니다. 그러면 노드의 외부 IP를 사용하여 서비스에 외부적으로 액세스할 수 있습니다.
...
spec:
type: LoadBalancer
externalIPs:
- 192.168.0.10
노드 포트 사용:
$ kubectl run user-login --replicas=2 --labels="run=user-login" --image=kingslayerr/teamproject:version2 --port=5000
$ kubectl expose deployment user-login --type=NodePort --name=user-login-service
$ kubectl describe services user-login-service
(포트 아래에 메모)
$ kubectl cluster-info
(IP-> 마스터가 실행 중인 IP 가져오기)
귀하의 서비스는 다음 사이트에서 이용 가능합니다
나는 kubadem을 사용하여 단일 노드 k8s 클러스터를 만들었다. 와 를 시도해보니 외부 IP가 보류 중으로 표시되었습니다.
$ kubectl get svc -n argocd argocd-server
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-server LoadBalancer 10.107.37.153 <pending> 80:30047/TCP,443:31307/TCP 110s
이 경우 서비스를 다음과 같이 패치했습니다:
kubectl patch svc <svc-name> -n <namespace> -p '{"spec": {"type": "LoadBalancer", "externalIPs":["172.31.71.218"]}}'
그 후, 공용 IP를 통해 서비스하기 시작했습니다
$ kubectl get svc argo-ui -n argo
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argo-ui LoadBalancer 10.103.219.8 172.31.71.218 80:30981/TCP 7m50s
만약 당신이 미니큐브를 사용하고 있다면, 마법 명령이 있습니다!
$ minikube tunnel
누군가 이것으로 몇 분을 절약할 수 있기를 바랍니다.
참조 링크
동일한 문제:
os>svectl get svc 오른쪽 단추 톱니-워드 프레스
이름 유형 클러스터-IP 외부-IP 포트(S) 로드 밸런서 10.97.130.7 "보류 중" 80:30454/TCP, 443:30427/TCP
os>minikube 서비스 목록
|-------------|----------------------------|--------------------------------|
| 네임스페이스 | 이름 | URL |
|-------------|----------------------------|--------------------------------|
| default | kubernetes | 노드 포트 없음
| default | 오른쪽-sabert tooth-mariadb | 노드 포트 없음 |
| 채무 불이행 | | |
| | | |
| kube-system | kube-dns | 노드 포트 없음 |
| kube-system | 틸러-deploy | 노드 포트 없음 |
|-------------|----------------------------|--------------------------------|
그러나 그것을 통해 접근할 수 있다.
기존 서비스를 삭제하고 동일한 새 서비스를 생성하여 문제를 해결했습니다. 내 문제는 외부 끝점이 보류 중이도록 정의된 로드 밸런싱 IP가 사용된다는 것입니다. 내가 새로운 로드 밸런싱 IP를 변경했을 때 여전히 작동하지 않았다.
마지막으로 기존 서비스를 삭제하고 새로운 서비스를 생성하여 문제를 해결했습니다.
에서 실행 중인 경우 기본값을 사용하지 않는 경우 네임스페이스를 언급하는 것을 잊지 마십시오.
미니큐브 서비스 << service_name >> --url --syslog=< namespace_name >>
큐브 컨트롤러 로그를 확인합니다. 클러스터를 설정하여 이 문제를 해결할 수 있었습니다클러스터를 배포한 ec2 인스턴스에 대한 ID 태그입니다.
@Javier의 대답에 따라. 로드 밸런서에 대해 "외부 IP 패치"를 적용하기로 결정했습니다.
$ kubectl patch service my-loadbalancer-service-name \
-n lb-service-namespace \
-p '{"spec": {"type": "LoadBalancer", "externalIPs":["192.168.39.25"]}}'
이렇게 하면 해당 '보류 중'이 클러스터에 사용할 수 있는 패치가 적용된 새 IP 주소로 대체됩니다.
이것에 대한 더 많은 것을 위해. 의 게시물을 참조하십시오
그것을 하는 가장 깨끗한 방법은 아니다. 일시적인 해결책이 필요했어요. 이것이 누군가에게 도움이 되기를 바란다.
Minikube를 사용할 때 다음을 실행하여 서비스에 액세스할 수 있는 IP 및 포트를 얻을 수 있습니다:
minikube service [service name]
예:
minikube service kubia-http
지원되는 클라우드(aws, azure, gcloud 등)가 아닌 경우..) MetalLB가 없으면 LoadBalancer를 사용할 수 없지만 아직 베타 버전입니다..
미니큐브를 사용하는 경우 터미널에서 아래 명령을 실행합니다,
$ minikube ip
$ 172.17.0.2 // then
$ curl http://172.17.0.2:31245
or simply
$ curl http://$(minikube ip):31245
로드 밸런서 서비스 유형은 기본 인프라가 로드 밸런서의 자동 생성을 지원하고 구글 클라우드 플랫폼과 AWS의 경우처럼 쿠버네티스에서 각각의 지원을 받는 경우에만 작동합니다. 이러한 기능이 구성되지 않은 경우 LoadBalancer IP 주소 필드는 채워지지 않고 대기 상태이며 서비스는 NodePort 유형 서비스와 동일한 방식으로 작동합니다
포드가 호스팅되는 노드의 IP(노드의 개인 IP)에 패치를 적용할 수 있습니다. 이것은 쉬운 해결 방법입니다.
위의 게시물들을 참고하여, 다음은 나에게 도움이 되었습니다:
kubectl 패치 서비스 my-loadbalancer-service-name \-nlb-service-namespace \-p '{"spec": {"type": "LoadBalancer", "외부"IPs":["xxx.xxx.xxx .xxx 물리적 서버의 개인 IP - 노드 - 배포가 수행되는 "]}}'
개인 k8s 클러스터인 경우 MetalLB가 더 적합합니다. 다음은 단계입니다.
1단계: 클러스터에 MetalLB 설치
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
# On first install only
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
2단계: 구성 맵을 사용하여 구성
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 172.42.42.100-172.42.42.105 #Update this with your Nodes IP range
3단계: 외부 IP(개인 IP일 수 있음)를 얻기 위해 서비스를 만듭니다.
FYR:
MetalLB 설치 전:
MetalLB 설치 후:
에서 실행하는 동안 이 오류가 발생한 사용자를 위한 솔루션을 추가하는 중입니다.
첫 번째 실행:
kubectl describe svc <service-name>
그런 다음 아래 출력 예제의 필드를 검토합니다:
Name: some-service
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"some-service","namespace":"default"},"spec":{"ports":[{"port":80,...
Selector: app=some
Type: LoadBalancer
IP: 10.100.91.19
Port: <unset> 80/TCP
TargetPort: 5000/TCP
NodePort: <unset> 31022/TCP
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal EnsuringLoadBalancer 68s service-controller Ensuring load balancer
Warning SyncLoadBalancerFailed 67s service-controller Error syncing load balancer: failed to ensure load balancer: could not find any suitable subnets for creating the ELB
오류 메시지를 검토합니다:
Failed to ensure load balancer: could not find any suitable subnets for creating the ELB
제 경우, ELB를 만들기 위해 적절한 서브넷이 제공되지 않은 이유는 다음과 같습니다:
EKS 클러스터가 잘못된 서브넷 그룹(공용 서브넷 대신 내부 서브넷)에 배포되었습니다. (*) 기본적으로 주석이 제공되지 않은 경우 유형의 서비스가 공용 방향 로드 밸런서를 만듭니다.
언급된 요구 사항에 따라 서브넷에 태그가 지정되지 않았습니다.
VPC 태그 지정:
Key: kubernetes.io/cluster/yourEKSClusterName
Value: shared
다음을 사용하여 공용 서브넷:
Key: kubernetes.io/role/elb
Value: 1
서비스 노드 포트 클러스터를 노출하는 세 가지 유형이 있습니다IP 로드 밸런서
로드 밸런서를 사용할 때는 기본적으로 클라우드 공급자에게 온라인으로 액세스할 수 있는 DNS를 제공해 달라고 요청합니다. 도메인 이름이 아니라 DNS입니다.
따라서 로드 밸런서 유형은 로컬 미니큐브 환경에서 작동하지 않습니다.
MicroK8s를 사용하는 경우: 네트워크 로드 밸런서가 필요합니다.
MicroK8은 metalb와 함께 제공되며 다음과 같이 활성화할 수 있습니다:
microk8s enable metallb
그러면 실제 IP 주소로 바뀌어야 합니다.
서비스를 배포하는 서브넷일 수 있습니다. IP가 충분하지 않습니다
Kubernetes에서는 Pods 집합에서 실행되는 응용 프로그램을 네트워크 서비스로 노출하는 일반적인 방법을 서비스라고 합니다. 쿠베르네테스에는 네 가지 종류의 서비스가 있다.
클러스터 IP 서비스는 클러스터 내에서만 연결할 수 있습니다.
노드 포트 클러스터 외부에서 다음을 사용하여 서비스를 통신할 수 있습니다. 기본 노드 포트 범위는 입니다. 이 범위는 클러스터 생성 시 정의하여 변경할 수 있습니다.
LoadBalancer 클라우드 제공자의 로드 밸런서를 사용하여 서비스를 외부에 노출합니다.
ExternalName 값이 포함된 CNAME 레코드를 반환하여 서비스를 외부 이름 필드의 내용(예: foo.bar.example.com )에 매핑합니다. 어떤 종류의 프록시도 설정되지 않았습니다.
LoadBalancer만 External-IP 열에 대한 값을 제공하며, Kubernetes 클러스터가 해당 특정 서비스에 대한 IP 주소를 할당할 수 있는 경우에만 작동합니다. 로드 밸런서를 사용하여 IP를 로드 밸런서 서비스에 프로비저닝할 수 있습니다.
당신의 의심이 사라지기를 바랍니다.
사용 사례의 경우 로드 밸런서를 사용할 수 없기 때문에 로드 밸런서 유형 대신 NordPort 서비스를 사용하는 것이 가장 좋습니다.
도커 데스크톱에서 이 오류가 발생했습니다. 종료하고 다시 켭니다(도커 데스크톱). 몇 초가 걸렸고, 잘 작동했어요.
베어 메탈을 사용하는 경우 NodePort 유형이 필요합니다
LoadBalancer는 Digital Ocean, AWS 등의 다른 클라우드 공급자에서 기본적으로 작동합니다
k edit service ingress-nginx-controller
type: NodePort
spec:
externalIPs:
- xxx.xxx.xxx.xx
공용 IP 사용
온프리미엄 클라우드에서 이 작업을 수행하려면 LB 인스턴스를 생성하기 위한 L4LB 서비스가 필요합니다.
그렇지 않으면 당신은 당신이 설명한 끝없는 "보류 중" 메시지로 끝난다. 비디오에서 볼 수 있습니다:
이 문제를 해결하기 위해 오픈 소스 도구를 사용할 수 있습니다. 비디오는 자동화 프로세스가 어떻게 작동해야 하는지에 대한 몇 가지 지침을 제공합니다.
미니큐브 터널
나의 경우 아래의 해결책이 효과가 있다.
먼저 다음 명령을 사용해 보십시오:
minikube tunnel
사용자에게 적합하지 않은 경우 다음을 수행하십시오:
컨테이너를 다시 시작합니다.
docker minikube stop
그리고나서
docker minikube start
그 재실행 후
minikube dashboard
완료 후 실행:
minikube tunnel
AWS EKS에서도 같은 문제가 있었습니다
해결 방법은 다음과 같습니다:
Amazon Virtual Private Cloud(Amazon VPC) 서브넷에 대한 올바른 태그
클러스터의 IAM 역할에 필요한 AWS IAM(Identity and Access Management) 권한 유효한 Kubernetes 서비스 정의 계정 제한 내에 유지되는 로드 밸런서 서브넷에 충분한 사용 가능한 IP 주소
다음 태그를 확인해야 합니다
Key: kubernetes.io/cluster/yourEKSClusterName
Value: shared
Key: kubernetes.io/role/elb
Value: 1
Key: kubernetes.io/role/internal-elb
Value: 1
참고로, 작업 중인 영역에 대해 sts가 활성화되었는지 확인하십시오. sts 설정은 사용자, 영역 설정에서 찾을 수 있습니다.
저도 같은 문제가 있어요. 윈도우 10 데스크톱 + 도커 데스크톱 4.7.1 (77678) + 미니큐브 v1.25.2
내 편에 따라, 나는 다음과 같이 결정한다:
PS C:\WINDOWS\system32> kubectl expose deployment sito-php --type=LoadBalancer --port=8080 --name=servizio-php
service/servizio-php exposed
PS C:\WINDOWS\system32> minikube tunnel
* Tunnel successfully started
* NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
* Starting tunnel for service servizio-php.
PS E:\docker\apache-php> kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 33h
servizio-php LoadBalancer 10.98.218.86 127.0.0.1 8080:30270/TCP 4m39s
브라우저가 열려 있습니다
이전 서비스를 모두 삭제하고 새 서비스를 생성하여 문제를 해결했습니다. IP가 이전 서비스에 바인딩되었습니다. ""를 시도한 다음 모든 svc의 ""을 하나씩 삭제하십시오
종류 또는 의 서비스를 사용하고 액세스하려는 사용자.
우리는 외부 IP가 로컬 시스템의 서비스에 액세스하지 못하도록 한다. 그래서 좋은 옵션은 미니큐브 IP를 사용하는 것이다
서비스가 노출되면 다음 명령을 사용하여 IP를 가져옵니다.
minikube service service-name --url
이제 해당 URL을 사용하여 사용자의 목적을 달성하십시오.
시간이 지남에 따라, 우리는 쿠버네티스의 네트워킹을 클라우드 공급업체에 의존한다. 그러나 베어메탈에서 쿠버네티스를 실행할 때 로드밸런서와 같은 서비스를 통합하는 것은 더 어려울 수 있다.
그리고 다른 사람들과 마찬가지로, 나는 내 서비스가 상태인 도커 컨테이너 "노드"를 사용하여 로컬 쿠버네티스 클러스터를 설치하는 것과 같은 문제를 겪었다.
내 생각은:
Istio와 같은 입력을 사용하여 클러스터를 설치하여 요청을 프록시합니다(Istio에서는 들어오는 트래픽에 대한 로드 밸런서 역할을 할 수 있는 입력 컨트롤러를 배포합니다).
NodePort/LoadBalancer 서비스 및 사용의 기본 애드혹 솔루션(특히 보안되지 않은 환경에서 사용되거나 무단으로 사용되는 경우 Kubernetes 클러스터가 잠재적으로 보안 위험에 노출될 수 있음)
다음을 통해 포드에 액세스할 수도 있습니다
kubectl 포트 포워드 포드 이름 로컬 포트:포드 포트
- 이 경우의 또 다른 솔루션(온프레미스 클러스터)은 표준 라우팅 프로토콜을 사용하는 쿠버네티스를 위한 네트워크 로드 밸런서 구현이다.
When using metallb with kind we are going to deploy it in l2-mode. This means that we need to be able to connect to the IP addresses of the node subnet. If you are using Linux to host a kind cluster. You will not need to do this as the kind node IP addresses are directly attached.
A great article from Duffie Cooley , explains the process in details