I created a kubernetes pod efgh in namespace ns1
kubectl run efgh --image=nginx -n ns1
I created another pod in default namespace
kubectl run apple --image=nginx
I created a service efgh in namespace ns1
kubectl expose pod efgh --port=80 -n ns1
Now I created a network policy to block incoming connections to the pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: ns1
spec:
podSelector:
matchLabels:
run: efgh
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
project: ns1
- from:
- namespaceSelector:
matchLabels:
project: default
podSelector:
matchLabels:
run: apple
ports:
- protocol: TCP
port: 80
Checking the pods in ns1 gives me
NAME READY STATUS RESTARTS AGE IP
efgh 1/1 Running 0 3h4m 10.44.0.4
Checking the services in ns1 gives me
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
efgh ClusterIP 10.109.170.238 <none> 80/TCP 164m
Once I open terminal in apple pod and run below it works
curl http://10-44-0-4.ns1.pod
curl http://10.44.0.4
but when I try curl by trying to access the pod through the service it fails.
curl http://10.109.170.238
If i delete the network policy the above curl works
I think this is an issue with my local kubernetes cluster. I tried elsewhere it works
When I did port forward
root@kubemaster:/home/vagrant# kubectl port-forward service/efgh 8080:80 -n ns1
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
See below, more details here ServiceTypes
Publishing Services (ServiceTypes)
For some parts of your application (for example, frontends) you may want to expose a Service onto an external IP address, that's outside of your cluster.
Kubernetes ServiceTypes allow you to specify what kind of Service you want. The default is ClusterIP.
Type values and their behaviors are:
ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
NodePort: Exposes the Service on each Node's IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You'll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
LoadBalancer: Exposes the Service externally using a cloud provider's load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
ExternalName: Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.