从Rancher 1.x迁移至2.X：Nginx配置问题求助

Hey there, let's tackle your migration questions one by one to get you sorted out with Rancher 2.x:

1. Nginx Configuration: Cluster IP + Target Port vs. Published Port? #

First, let's clarify the port definitions from your Service setup:

• Target Port: This maps directly to the port your container is listening on (your private container port from Rancher 1.x).
• Published Port: If your Service is set to NodePort type, this is the port opened on every cluster node that forwards traffic to the Service's Cluster IP + Target Port. If it's ClusterIP type, this port won't exist (ClusterIP is only accessible within the cluster).

Your choice depends on where your Nginx is deployed:

Option A: Nginx is outside the Kubernetes cluster #

If your Nginx runs on a separate server (like your current setup referencing host IPs), you need to use the Published Port (NodePort) plus any cluster node's IP. This works just like your Rancher 1.x setup—traffic hits the node's published port, then gets routed to the Service's backend pods.

Just update your Nginx config to point to a cluster node IP instead of your old Rancher 1.x host IP:

location /environment1/applicationStack{
    proxy_pass http://<cluster-node-ip>:<published-node-port>/;
}

Option B: Nginx is deployed as a Pod inside the cluster #

This is the more efficient approach. Instead of using Cluster IP (which is stable but less flexible), use the Service's DNS name plus the Target Port. Kubernetes automatically assigns DNS entries to Services in the format:
{service-name}.{namespace}.svc.cluster.local

For example, if your applicationStack Service is in the environment1 namespace, your Nginx config would look like:

location /environment1/applicationStack{
    proxy_pass http://applicationStack.environment1.svc.cluster.local:<target-port>/;
}

This is better than hardcoding Cluster IP because if you ever re-create the Service, the DNS name stays the same—no need to update Nginx.

Pro Tip: Consider Rancher 2.x Ingress #

Instead of maintaining your own Nginx, Rancher 2.x integrates with Kubernetes Ingress Controllers. You can define Ingress rules to route traffic to different Services based on paths or domains, which replaces your custom Nginx config with native Kubernetes resources. It's easier to manage alongside your Rancher workloads!

2. Will Travis CI Deployments Impact the Service? #

Great news—no, your Service won't be affected when Travis pushes new pods via Deployment updates. Here's why:

• Kubernetes Services use label selectors to identify which pods to route traffic to. As long as your new pods have the same labels as the old ones (which your migration-generated Deployment YAML should ensure), the Service will automatically detect and include the new pods in its load balancing pool.
• When Travis triggers a Deployment update, Kubernetes uses a rolling update strategy by default: it spins up new pods, waits for them to be ready, then terminates old pods one by one. Traffic is seamlessly shifted to new pods without downtime, and the Service itself remains completely stable throughout the process.

This is a core strength of Kubernetes (and Rancher 2.x) compared to Rancher 1.x—Services act as a stable entry point for your workloads, regardless of pod churn from CI/CD or scaling.

内容的提问来源于stack exchange，提问作者Gabripp