Hindi - Ht Cloud

Exposing Services in Kubernetes

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!

कुबरनेटीज में सेवाओं को उभारने के विभिन्न तरीके हैं ताकि आंतरिक और बाहरी अंतःस्थापनों को उन तक पहुंच मिल सके। यह कुबरनेटीज कॉन्फ़िगरेशन बहुत महत्वपूर्ण होती है क्योंकि प्रशासक हमलावरों को सेवाओं तक पहुंच दे सकता है जिनकी उन्हें पहुंच नहीं होनी चाहिए।

स्वचालित गणना

सार्वजनिकता के लिए सेवाओं को उभारने के तरीकों की गणना शुरू करने से पहले, जानें कि यदि आप नेमस्पेस, सेवाएं और इंग्रेस की सूची बना सकते हैं, तो आप इसके साथ सार्वजनिकता में उभारे गए सभी को खोज सकते हैं:

kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
echo "Namespace: $ns"
kubectl get service -n "$ns"
kubectl get ingress -n "$ns"
echo "=============================================="
echo ""
echo ""
done | grep -v "ClusterIP"
# Remove the last '| grep -v "ClusterIP"' to see also type ClusterIP

ClusterIP

एक ClusterIP सेवा Kubernetes की default सेवा है। यह आपको आपके क्लस्टर के अंदर एक सेवा प्रदान करता है जिसे आपके क्लस्टर के अंदर के अन्य ऐप्स तक पहुंच सकते हैं। यहां कोई बाहरी पहुंच नहीं होती है।

हालांकि, इसे Kubernetes Proxy का उपयोग करके पहुंचा जा सकता है:

kubectl proxy --port=8080

अब, आप Kubernetes API के माध्यम से सेवाओं तक पहुंचने के लिए इस तरीके का उपयोग कर सकते हैं:

http://localhost:8080/api/v1/proxy/namespaces/<नेमस्पेस>/services/<सेवा-नाम>:<पोर्ट-नाम>/

उदाहरण के लिए, आप निम्नलिखित URL का उपयोग कर सकते हैं:

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

इस सेवा तक पहुंचने के लिए:

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

इस तकनीक के लिए आपको kubectl को प्रमाणित उपयोगकर्ता के रूप में चलाने की आवश्यकता होती है।

NodePort

NodePort सभी नोड्स पर एक विशिष्ट पोर्ट खोलता है (वीएम), और इस पोर्ट पर भेजे गए किसी भी ट्रैफिक को सेवा के लिए अग्रेषित किया जाता है। यह आमतौर पर एक बहुत बुरा विकल्प होता है।

NodePort स्पष्टीकरण का एक उदाहरण:

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

यदि आप yaml में nodePort को निर्दिष्ट नहीं करते हैं (यह पोर्ट खोला जाएगा) तो 30000-32767 रेंज में एक पोर्ट का उपयोग होगा।

LoadBalancer

यह एक क्लाउड प्रदाता के लोड बैलेंसर का उपयोग करके सेवा को बाहरी रूप से उभारता है। GKE पर, यह एक नेटवर्क लोड बैलेंसर चलाएगा जो आपको एक एकल IP पता प्रदान करेगा जो सभी ट्रैफिक को आपकी सेवा के लिए फ़ॉरवर्ड करेगा।

आपको प्रति उभारी गई सेवा के लिए एक लोड बैलेंसर के लिए भुगतान करना होगा, जो महंगा हो सकता है।

ExternalName

ExternalName प्रकार की सेवाएं एक DNS नाम को एक सेवा से मैप करती हैं, my-service या cassandra जैसे आम चयनकर्ता के बजाय। आप spec.externalName पैरामीटर के साथ इन सेवाओं को निर्दिष्ट करते हैं।

उदाहरण के लिए, इस सेवा परिभाषा में, prod नेमस्थान में my-service सेवा को my.database.example.com से मैप किया जाता है:

apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com

जब my-service.prod.svc.cluster.local होस्ट को खोजा जाता है, क्लस्टर DNS सेवा एक CNAME रिकॉर्ड लौटाती है जिसका मान my.database.example.com होता है। my-service तक पहुंचने का तरीका अन्य सेवाओं के साथ एक ही तरीके से काम करता है, लेकिन इसमें एक महत्वपूर्ण अंतर होता है कि रीडायरेक्शन DNS स्तर पर होता है और प्रॉक्सी या फ़ॉरवर्डिंग के माध्यम से नहीं होता है।

बाहरी IP

क्लस्टर में प्रवेश करने वाले ट्रैफ़िक को बाहरी IP (गंतव्य IP के रूप में), सेवा पोर्ट पर, सेवा अंत तक रूट किया जाएगा। externalIPs को Kubernetes द्वारा प्रबंधित नहीं किया जाता है और इसकी जिम्मेदारी क्लस्टर प्रशासक की होती है।

सेवा स्पेक में, externalIPs को किसी भी ServiceTypes के साथ निर्दिष्ट किया जा सकता है। नीचे दिए गए उदाहरण में, "my-service" क्लाइंट्स द्वारा "80.11.12.10:80" (externalIP:port) पर पहुंचा जा सकता है।

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10

Ingress

उपरोक्त सभी उदाहरणों के विपरीत, Ingress एक सेवा के प्रकार नहीं है। इसके बजाय, यह कई सेवाओं के सामने बैठता है और एक "स्मार्ट राउटर" या क्लस्टर में प्रवेशद्वार के रूप में कार्य करता है।

आप Ingress के साथ कई अलग-अलग कार्य कर सकते हैं, और इसके पास विभिन्न क्षमताओं वाले कई प्रकार के Ingress controllers होते हैं।

डिफ़ॉल्ट GKE Ingress controller आपके लिए एक HTTP(S) Load Balancer चलाएगा। इससे आप पथ आधारित और उपडोमेन आधारित रूटिंग कर सकते हैं। उदाहरण के लिए, आप foo.yourdomain.com पर सभी को foo सेवा में भेज सकते हैं, और yourdomain.com/bar/ पथ के नीचे सभी को bar सेवा में भेज सकते हैं।

GKE पर Ingress ऑब्जेक्ट के लिए YAML इस तरह से हो सकता है:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080

संदर्भ

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!
PreviousKubelet Authentication & AuthorizationNextAttacking Kubernetes from inside a Pod

Last updated