minikue ssh到node上可以直接訪問pod 和 service。 例如curl pod_ip 或者curl servcie_ip。

如果想在外面訪問：

需要ingress

或者nodePort類型，curl $(minikube ip)

或者需要port-forward，curl $(minikube ip)

here’s a short explanation of the differences between ingress, NodePort, and port-forward in Kubernetes:

• NodePort:
  • Opens a specific port on each node of the cluster.
  • A service is accessible externally via node’s IP address and the assigned port.
  • Typically used for simple external access without needing a dedicated load balancer or advanced routing rules.
• Ingress:
  • An API object that manages external access to services in a cluster, typically HTTP/HTTPS.
  • Provides features such as path-based routing, SSL termination, and name-based virtual hosting.
  • Requires an Ingress Controller (e.g., NGINX, Traefik) to handle requests and route traffic internally.
• Port-Forward:
  • Forwards traffic from a local machine to a specific Pod in the cluster.
  • Used primarily for local debugging, development, or testing scenarios—no need to expose the service to the outside world.
  • Not meant for broad user traffic; the developer manually runs “kubectl port-forward” to open that tunnel.

In summary:

• Use NodePort when you want a simple way to expose your service on a fixed port across all nodes.
• Use Ingress when you need advanced routing (e.g., host-based or path-based rules) and want a consolidated entry point for multiple services.
• Use Port-Forward when you only need quick, local access to a Pod for debugging without using a public or external endpoint.

here’s a concise guide on exposing a non-HTTP port with load balancing in Kubernetes:

1. Create a Service of type “LoadBalancer”
   • While Ingress resources often deal with HTTP/HTTPS traffic, creating a Service of type LoadBalancer can handle generic TCP/UDP ports.
   • Example YAML:

   apiVersion: v1
   kind: Service
   metadata:
     name: my-tcp-service
   spec:
     type: LoadBalancer
     ports:
       - port: 12345          # The port your application listens on
         targetPort: 12345    # Container port
         protocol: TCP
     selector:
       app: my-tcp-app
       

   • Once deployed, your cloud provider (e.g., AWS, GCP, Azure) typically provisions a load balancer that forwards external traffic on port 12345 to your Pod(s).
   • If you’re on bare-metal Kubernetes (no cloud provider), you can look into technologies like MetalLB.
2. Ensure your application listens on the correct port
   • Inside the Pod, confirm that your application container is listening on port 12345. This must match targetPort in your Service definition.
3. Use NodePort if LoadBalancer isn’t available
   • If your environment doesn’t support a LoadBalancer (e.g., a bare-metal cluster without additional LB provisioning), you could use a NodePort service and place an external load balancer or proxy in front of your cluster that balances across the node IPs.
   • But with a cloud provider or a solution like MetalLB, type: LoadBalancer is simpler and more direct.