![[Kubernetes] Ingress (인그레스)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FYtKIl%2FbtrC2vuWeMi%2FPpCMampyAlKQK8UllQsyd1%2Fimg.png)
✔️ Ingress
Ingress 라는 오브젝트 리소스를 구현해주는 것이 Ingress Controller이다.
쿠버네티스의 핵심은 Controller Manager이다.
METALLB에서도 controller가 실질적인 로드밸런서 기능을 한다.
컨트롤러라는 이름이 붙은 것들은 대부분 구현하고 제어하는 역할을 한다.
따라서 Ingress 리소스가 작동하려면, Ingress Controller가 반드시 필요하다.
프로젝트로서 쿠버네티스는 AWS, GCE와 nginx 인그레스 컨트롤러를 지원하고 유지한다.
vagrant@node1 ~ kubectl api-resources | grep ingress
ingressclasses networking.k8s.io/v1 false IngressClass
ingresses ing networking.k8s.io/v1 true IngressIngress-nginx controller는 Ingress를 구현하기 위한 컨트롤러이고 실제로 생성해야하는 것은 Ingress라는 리소스이다.
ingresses라는 이름을 사용하며 shortname은 ing networking.k8s.io 그룹에 속하며 NS를 사용하고 KIND는 Ingress이다.
Ingress는 L7 로드밸런서이다.
AWS에서는 어플리케이션 계층인 L7 로드밸런서인 ALB에 대응된다.
SVC 중 LoadBalancer 타입은 L4 로드밸런서이다. 포트를 통해 부하 분산 시킨다.
vagrant@node1 ~ kubectl explain ingress.spec 1.19에 stable되었으며 상당히 오랜 기간 베타 버전이었다.
클러스터에는 Ingress라는 리소스가 만들어지게 되며 서비스가 있어야 한다.
서비스는 일반적으로 NodePort를 사용한다. (반드시 NodePort여야 하는 것은 아니다.)
Ingress의 라우팅 서비스에 의해 SVC를 추가할 수 있다.
만약 우리가 사용하는 도메인이 abc.com이라고 하자
도메인에서 /auth 라는 경로를 접근하면 서비스 1에 전달하고 /board 라는 경로에 접근하면 서비스 2에 전달하고
/info 라고 하는 경로에 접근하면 서비스 3에 전달하고 아예 다르게 xyz.com 으로 접속하면 서비스 4로 전달한다.
도메인 주소라던가 경로 즉, URL을 보고 라우팅 규칙에 따라서 원하는 서비스로 라우팅해준다.
vagrant@node1 ~ kubectl api-resources | grep ingress
ingressclasses networking.k8s.io/v1 false IngressClass
ingresses ing networking.k8s.io/v1 true Ingress
vagrant@node1 ~ kubectl explain ingress.spec
ingressClassName <string>
IngressClassName is the name of the IngressClass cluster resource. The
associated IngressClass defines which controller will implement the
resource. This replaces the deprecated `kubernetes.io/ingress.class`
annotation. For backwards compatibility, when that annotation is set, it
must be given precedence over this field. The controller may emit a warning
if the field and annotation have different values. Implementations of this
API should ignore Ingresses without a class specified. An IngressClass
resource may be marked as default, which can be used to set a default value
for this field. For more information, refer to the IngressClass
documentation.ingressclasses라는 오브젝트가 있다.
우리는 현재 nginx로 구현된 Ingress Controller 하나가 있다.
이런 Controller를 여러개(ex. ALB, nginx, haproxy, apache)세팅할 수도 있는데 하나 하나를 클래스로 만들어놓을 수 있다. 어떤 클래스를 가지고 만들 것이냐 컨트롤러가 여러개인 경우 선택할 수 있다.
rules <[]Object>
A list of host rules used to configure the Ingress. If unspecified, or no
rule matches, all traffic is sent to the default backend.라우팅 정책이다.
vagrant@node1 ~ kubectl explain ingress.spec.rules
FIELDS:
host <string>
Host is the fully qualified domain name of a network host, as defined by
RFC 3986. Note the following deviations from the "host" part of the URI as
defined in RFC 3986: 1. IPs are not allowed. Currently an IngressRuleValue
can only apply to the IP in the Spec of the parent Ingress.
2. The `:` delimiter is not respected because ports are not allowed.
Currently the port of an Ingress is implicitly :80 for http and :443 for
https. Both these may change in the future. Incoming requests are matched
against the host before the IngressRuleValue. If the host is unspecified,
the Ingress routes all traffic based on the specified IngressRuleValue.
Host can be "precise" which is a domain name without the terminating dot of
a network host (e.g. "foo.bar.com") or "wildcard", which is a domain name
prefixed with a single wildcard label (e.g. "*.foo.com"). The wildcard
character '*' must appear by itself as the first DNS label and matches only
a single label. You cannot have a wildcard label by itself (e.g. Host ==
"*"). Requests will be matched against the Host field in the following way:
1. If Host is precise, the request matches this rule if the http host
header is equal to Host. 2. If Host is a wildcard, then the request matches
this rule if the http host header is to equal to the suffix (removing the
first label) of the wildcard rule.
http <Object>host와 http가 있다. 각각은 프로토콜을 의미한다.
http인지 https인지의 차이가 있는 것이며 tls가 https 관련 구성을 하는 부분이다.
vagrant@node1 ~ kubectl explain ingress.spec.rules.hosthost는 더이상 하위 내용이 없으며 말그대로 hostName을 포함하고 있다.
일반적으로 www.naver.com에서 www가 hostName이고 naver.com이 Domain이다.
(e.g. "foo.bar.com") (e.g. "*.foo.com") - wildcard 마스크도 가능하다. 앞에 어떤 것이 붙던 상관없다.
이때 host에 지정하는 도메인은 실제로 존재하는 도메인이어야 한다.
vagrant@node1 ~ kubectl explain ingress.spec.rules.http.paths
FIELDS:
backend <Object> -required-
Backend defines the referenced service endpoint to which the traffic will
be forwarded to.
path <string>
Path is matched against the path of an incoming request. Currently it can
contain characters disallowed from the conventional "path" part of a URL as
defined by RFC 3986. Paths must begin with a '/' and must be present when
using PathType with value "Exact" or "Prefix".
pathType <string> -required-
PathType determines the interpretation of the Path matching. PathType can
be one of the following values: * Exact: Matches the URL path exactly. *
Prefix: Matches based on a URL path prefix split by '/'. Matching is done
on a path element by element basis. A path element refers is the list of
labels in the path split by the '/' separator. A request is a match for
path p if every p is an element-wise prefix of p of the request path. Note
that if the last element of the path is a substring of the last element in
request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but
does not match /foo/barbaz).
* ImplementationSpecific: Interpretation of the Path matching is up to the
IngressClass. Implementations can treat this as a separate PathType or
treat it identically to Prefix or Exact path types. Implementations are
required to support all path types.필수이다. www.xyz.com/ 부분을 의미한다.
세가지 종류가 있다.
- backend : 실제 연결하고자 하는 서비스, 룰 정책을 통해 어떤 서비스로 연결할 것인지
- path : 지정하지 않으면 기본적으로 /(root)
- pathType : Exact, Prefix, ImplementationSpecific 세가지 중에 하나를 선택할 수 있으며
Exact,Prefix를 일반적으로 사용한다.Exact: path가 정확히 일치해야 한다. (ex. /info)Prefix: path에 추가적인 문자가 붙어도 된다.
vagrant@node1 ~ kubectl explain ingress.spec.rules.http.paths.backend가장 중요한 부분으로 백엔드로 연결할 오브젝트가 어떤 종류의 오브젝트인가를 결정하며 대부분은 서비스이다.
확장을 위해 만들어놓은 형태이다.
vagrant@node1 ~ kubectl explain ingress.spec.rules.http.paths.backend.resource
FIELDS:
apiGroup <string>
APIGroup is the group for the resource being referenced. If APIGroup is not
specified, the specified Kind must be in the core API group. For any other
third-party types, APIGroup is required.
kind <string> -required-
Kind is the type of resource being referenced
name <string> -required-
Name is the name of resource being referenced리소스의 apiGroup은 무엇인지 kind는 무엇인지 name은 무엇인지 결정한다.
vagrant@node1 ~ kubectl explain ingress.spec.rules.http.paths.backend.service
KIND: Ingress
VERSION: networking.k8s.io/v1
RESOURCE: service <Object>
DESCRIPTION:
Service references a Service as a Backend. This is a mutually exclusive
setting with "Resource".
IngressServiceBackend references a Kubernetes Service as a Backend.
FIELDS:
name <string> -required-
Name is the referenced service. The service must exist in the same
namespace as the Ingress object.
port <Object>
Port of the referenced service. A port name or port number is required for
a IngressServiceBackend.
vagrant@node1 ~ kubectl explain ingress.spec.rules.http.paths.backend.service.port
FIELDS:
name <string>
Name is the name of the port on the Service. This is a mutually exclusive
setting with "Number".
number <integer>
Number is the numerical port number (e.g. 80) on the Service. This is a
mutually exclusive setting with "Name".실제 서비스를 정의하는 부분이다.
name: 참조할 실제 서비스의 이름port: 서비스에 실제 연결할 포트name: 포트 이름number: 포트 넘버
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /testpath
pathType: Prefix # 뒤에 추가 경로가 더 붙어도 된다.
backend:
service:
name: test
port:
number: 80PathType이 Prefix 이므로 x.x.x.x/testpath/ 뒤에 추가 경로가 붙어도 된다.
x.x.x.x/testpath/xxx 라는 경로로 들어오면 test라는 SVC로 연결시킨다. 포트는 80포트이다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-wildcard-host
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: "/bar"
backend:
service:
name: service1
port:
number: 80
- host: "*.foo.com"
http:
paths:
- pathType: Prefix
path: "/foo"
backend:
service:
name: service2
port:
number: 80Ingress Controller가 있고 리스트로 rule이 2개 있다. 이 때 순서가 중요하다.
만약 *.foo.com이 더 위에 선언되어 있었다면 모든 정책을 *.foo.com에 일치시킨다. 그렇게 되면 foo.bar.com은 매칭되지 않는다.
따라서 작은 scope 부터 먼저 지정하고 foo가 아니면 *.foo.com에 매칭된다.
foo.bar.com이면 path가 /bar 이고 service1로 매칭시킨다. 나머지 모든 경우는 service2로 매칭시킨다.
✔️ 실습
myweb-ing.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myweb-ing
spec:
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myweb-svc-np
port:
number: 80 vagrant@node1 ~/svc/ing kubectl create -f myweb-ing.yaml
ingress.networking.k8s.io/myweb-ing created
vagrant@node1 ~/svc/ing kubectl get all
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-l8kp9 1/1 Running 1 (12h ago) 2d6h
pod/myweb-rs-t2q4z 1/1 Running 1 (27h ago) 2d6h
pod/myweb-rs-zknfd 1/1 Running 2 (12h ago) 2d6h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 3d
service/myweb-svc-lb LoadBalancer 10.233.47.233 192.168.100.240 80:31313/TCP 2d6h
service/weather-ext-svc ExternalName <none> www.naver.com <none> 2d5h
NAME DESIRED CURRENT READY AGE
replicaset.apps/myweb-rs 3 3 3 2d6h모든 리소스에는 Ingress 리소스가 포함되어 있지 않다.
vagrant@node1 ~/svc/ing kubectl get ing
NAME CLASS HOSTS ADDRESS PORTS AGE
myweb-ing <none> * 192.168.100.100,192.168.100.101,192.168.100.102 80 51s
vagrant@node1 ~/svc/ing kubectl get po -n ingress-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-controller-2jrhn 1/1 Running 1 (12h ago) 44h 10.233.96.67 node2 <none> <none>
ingress-nginx-controller-2pk4g 1/1 Running 1 (27h ago) 44h 10.233.92.96 node3 <none> <none>
ingress-nginx-controller-cmzt4 1/1 Running 2 (12h ago) 44h 10.233.90.53 node1 <none> <none>모든 호스트의 ip가 찍힌다. L7 로드밸런서 역할을 하는 컨트롤러가 모든 노드에 하나씩 떠있기 때문이다.
따라서 어떤 노드로 접속해도 상관없다.
vagrant@node1 ~/svc/ing kubectl get all,ing
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-hb24t 1/1 Running 0 16s
pod/myweb-rs-l8kp9 1/1 Running 1 (12h ago) 2d6h
pod/myweb-rs-zknfd 1/1 Running 2 (13h ago) 2d6h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 3m27s
service/myweb-svc-np NodePort 10.233.57.207 <none> 80:31313/TCP 3m14s
NAME DESIRED CURRENT READY AGE
replicaset.apps/myweb-rs 3 3 3 2d6h
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.networking.k8s.io/myweb-ing <none> * 192.168.100.100,192.168.100.101,192.168.100.102 80 7m47s
만약 호스트가 없다면
vagrant@node1 ~/svc/ing kubectl describe ing myweb-ing
Name: myweb-ing
Namespace: default
Address: 192.168.100.100,192.168.100.101,192.168.100.102
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
*
/ myweb-svc-np:80 (10.233.90.54:8080,10.233.92.97:8080,10.233.96.68:8080)
Annotations: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 6s (x4 over 14m) nginx-ingress-controller Scheduled for sync
Normal Sync 6s (x4 over 14m) nginx-ingress-controller Scheduled for sync
Normal Sync 6s (x4 over 14m) nginx-ingress-controller Scheduled for syncHost는 * 모든 호스트가 나온다.
vagrant@node1 ~/svc/ing curl http://192.168.100.100 -v
* Trying 192.168.100.100:80...
* TCP_NODELAY set
* Connected to 192.168.100.100 (192.168.100.100) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.100.100
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 23 May 2022 13:21:18 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 28
< Connection: keep-alive
<
Hello World!
myweb-rs-l8kp9
* Connection #0 to host 192.168.100.100 left intact>: HTTP Request<: HTTP Response- GET 방식의 HTTP method를 의미하며 경로는 root 경로이고 HTTP 프로토콜 1.1 버전을 사용한다.
- Host : 192.168.100.100 → 호스트의 도메인 주소를 의미한다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myweb-ing
spec:
rules:
- host: '*.sohui.xyz'
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myweb-svc-np
port:
number: 80만약 도메인이 *.sohui.xyz 구성되어 있다고 가정하면 (실제로 해당 도메인이 존재해야한다.)
vagrant@node1 ~/svc/ing kubectl replace -f myweb-ing.yaml
ingress.networking.k8s.io/myweb-ing replaced
vagrant@node1 ~/svc/ing kubectl describe ing myweb-ing
Name: myweb-ing
Namespace: default
Address: 192.168.100.100,192.168.100.101,192.168.100.102
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
*.sohui.xyz
/ myweb-svc-np:80 (10.233.90.54:8080,10.233.92.97:8080,10.233.96.68:8080)
Annotations: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Sync 13s (x3 over 11m) nginx-ingress-controller Scheduled for sync
Normal Sync 13s (x3 over 11m) nginx-ingress-controller Scheduled for sync
Normal Sync 13s (x3 over 11m) nginx-ingress-controller Scheduled for sync- Host : *.sohui.xyz
- Path : /
- Backends : myweb-svc-np:80
vagrant@node1 ~/svc/ing curl http://192.168.100.100 -v
* Trying 192.168.100.100:80...
* TCP_NODELAY set
* Connected to 192.168.100.100 (192.168.100.100) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.100.100
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Date: Mon, 23 May 2022 13:23:26 GMT
< Content-Type: text/html
< Content-Length: 146
< Connection: keep-alive
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host 192.168.100.100 left intactRules 에서는 호스트가 *.sohui.xyz 형식이어야 하는데 Host: 192.168.100.100는 그렇지 않으므로 404 Not Found가 뜬다.
그렇다면 실제 도메인을 구입하지 않고 테스트하는 방법은 무엇인가 ?
✔️ 도메인 없이 테스트하는 방법
L7 로드밸런서는 주소와 연관있는 서비스이므로 반드시 호스트를 설정해야하는데 도메인이 없을 때 사용하는 방법들이 있다.
L4 IP SRC는 x.x.x.x DST는 192.168.100.100이 된다.
L7 HTTP 프로토콜이 존재하고 Host(요청하는 Server)의 주소가 192.168.100.100이 된다.
이는 일반적으로 사용하는 도메인 형태의 주소가 아니다.
Rules에서 입력하는 Host의 주소가 *.sohui.xyz 형태여야 라우팅 정책이 매칭되기 때문에 curl 명령을 실행했을 때 404 Not Found를 응답한다.
도메인이 있는 경우 달라진다.
웹 브라우저에서 www.google.com 이라고 입력하면 IP의 출발지는 웹 브라우저가 있는 시스템이 되며 목적지는 www.google.com 을 DNS Query해서 돌아온 IP 주소가 지정된다.
HTTP 헤더의 Host는 www.google.com이 된다.
만약 이름 형태의 FQDN을 지정하지 않고 1.1.1.1 형태로 지정하면 목적지도 1.1.1.1이 되는 것이고 HTTP 헤더의 Host 주소 또한 1.1.1.1 이 되는 것이다.
✔️ curl 명령 사용
curl 명령의 옵션 중에 --resolve 옵션이 존재한다.
vagrant@node1 ~/svc/ing curl --resolve www.sohui.xyz:80:192.168.100.100 http://www.sohui.xyz
Hello World!
myweb-rs-hb24thttp://www.sohui.xyz : 요청하는 주소, 실제로 존재하지 않음--resolve www.sohui.xyz:80:192.168.100.100 : www.sohui.xyz의 80번 포트는 192.168.100.100 으로 바꾸라는 뜻이다.
vagrant@node1 ~/svc/ing curl --resolve www.sohui.xyz:80:192.168.100.100 http://www.sohui.xyz -v
* Added www.sohui.xyz:80:192.168.100.100 to DNS cache
* Hostname www.sohui.xyz was found in DNS cache
* Trying 192.168.100.100:80...
* TCP_NODELAY set
* Connected to www.sohui.xyz (192.168.100.100) port 80 (#0)
> GET / HTTP/1.1
> Host: www.sohui.xyz
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 23 May 2022 13:32:45 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 28
< Connection: keep-alive
<
Hello World!
myweb-rs-l8kp9
* Connection #0 to host www.sohui.xyz left intactHost에서 보면 요청한 것은 www.sohui.xyz이기 때문에 www.sohui.xyz로 들어간다. 그리고 실제 192.168.100.100으로 통신하게 된다.
192.168.100.100가 IP의 목적지가 되며 port 80가 TCP 목적지 포트가 된다.
✔️ hosts 파일을 이용하는 방법
vagrant@node1 ~/svc/ing grep host /etc/nsswitch.conf
hosts: files dnsns는 네임서버를 의미한다. 그 중에서도 hosts 타입의 서버이다.files 의 의미는 /etc/hosts 이다.dns는 /etc/resolv.conf 파일에 지정되어 있는 DNS 서버
호스트의 이름을 풀이할 때(resolve할 때) /etc/hosts 파일을 먼저 본 후 /etc/resolv.conf파일을 본다.
이는 Windows에도 존재하고 DNS가 나오기 전부터 존재하던 파일이며 DNS 보다 우선순위가 높다.
/etc/hosts
127.0.0.1 localhost localhost.localdomain
# The following lines are desirable for IPv6 capable hosts
::1 localhost6 localhost6.localdomain
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
127.0.1.1 ubuntu-focal ubuntu-focal
127.0.2.1 k8s-node1 k8s-node1
# Ansible inventory hosts BEGIN
192.168.100.100 node1.cluster.local node1
192.168.100.101 node2.cluster.local node2
192.168.100.102 node3.cluster.local node3
# Ansible inventory hosts END
192.168.100.100 www.sohui.xyz # 수정한 부분해당 파일을 다음과 같이 수정하면
vagrant@node1 ~/svc/ing curl http://www.sohui.xyz
Hello World!
myweb-rs-zknfd이제부터 http://www.sohui.xyz 도메인을 풀어준다.
/etc/hosts 파일의 내용은 잘 관리해줘야 한다.
✔️ nip.io 서비스를 사용하는 방법
https://nip.io/
wildcard DNS for any IP Address - 와일드카드 DNS라고 하는 서비스이다.
무엇을 요청해도 응답을 돌려주는 DNS 서버이다.
vagrant@node1 ~/svc/ing host 10.10.10.10.nip.io
10.10.10.10.nip.io has address 10.10.10.10
vagrant@node1 ~/svc/ing host www.10.10.10.10.nip.io
www.10.10.10.10.nip.io has address 10.10.10.10
vagrant@node1 ~/svc/ing host www.10-10-10-10.nip.io
www.10-10-10-10.nip.io has address 10.10.10.10host 명령어를 사용할 때 맨 마지막에 항상 nip.ip를 붙여준다.
어떤 형태를 쓰던 주소에 쓰는 ip를 리턴시킨다.
nip.io라고 하는 도메인 앞에 주소 형태가 들어가면 인식해서 주소를 리턴해주는 서비스이다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myweb-ing
spec:
rules:
- host: '*.nip.io'
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myweb-svc-np
port:
number: 80 vagrant@node1 ~/svc/ing kubectl describe ing myweb-ing
Name: myweb-ing
Namespace: default
Address: 192.168.100.100,192.168.100.101,192.168.100.102
Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
Rules:
Host Path Backends
---- ---- --------
*.nip.io
/ myweb-svc-np:80 (10.233.90.54:8080,10.233.92.97:8080,10.233.96.68:8080) vagrant@node1 ~/svc/ing curl http://192-168-100-100.nip.io/
Hello World!
myweb-rs-zknfd
vagrant@node1 ~/svc/ing curl http://192-168-100-100.nip.io/
Hello World!
myweb-rs-zknfd
vagrant@node1 ~/svc/ing curl http://192-168-100-100.nip.io/
Hello World!
myweb-rs-hb24t다음과 같이 접속이 가능하다.
📌 sslip.io 서비스
sslip.io는 IPv6 까지 지원한다. 마찬가지로 테스트 용으로만 사용한다.
vagrant@node1 ~/svc/ing host 1.1.1.1.sslip.io
1.1.1.1.sslip.io has address 1.1.1.1
1.1.1.1.sslip.io mail is handled by 0 1.1.1.1.sslip.io.'DevOps > Kubernetes' 카테고리의 다른 글
| [Kubernetes] Readiness Probe (준비성 프로브) (0) | 2022.05.29 |
|---|---|
| [Kubernetes] Ingress Challenge (0) | 2022.05.29 |
| [Kubernetes] Service - ExternalName (0) | 2022.05.23 |
| [Kubernetes] Service - LoadBalancer ( + METALLB : on-prem 환경의 LB) (0) | 2022.05.23 |
| [Kubernetes] Service - NodePort (1) | 2022.05.23 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
![[Kubernetes] Readiness Probe (준비성 프로브)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdfgV6t%2FbtrC74ykhUm%2F8QJK9ZKUV9YDz6e2qYQiq1%2Fimg.png)
![[Kubernetes] Ingress Challenge](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FG31jb%2FbtrC1i4mLY7%2FjqpG8rktP9gJAPHjBHKFl1%2Fimg.png)
![[Kubernetes] Service - ExternalName](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbxD2GM%2FbtrCOqgelcG%2FZxP3rXEUyUkFxW2gVXWbkK%2Fimg.png)
![[Kubernetes] Service - LoadBalancer ( + METALLB : on-prem 환경의 LB)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdXwIWC%2FbtrCMLx70uW%2F1rPcePjKloKfIKGr7Ok1kk%2Fimg.png)