Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup policy-based routing so that traffic arriving on a tunnel interface leaves on same tunnel interface irrespective of rp_filter value #143

Merged
merged 1 commit into from
Sep 2, 2017

Conversation

murali-reddy
Copy link
Member

@murali-reddy murali-reddy commented Aug 30, 2017

Setup policy-based routing so that traffic arriving on a tunnel interface leaves on same tunnel interface irrespective of rp_filter value

  • add ip rule to look up traffic from the pods from a custom route table
  • in the custom route table, add entry to route traffic to remote node through tunnel interface

Fixes #138

…face leaves on same tunnel interface irrespective of rp_filter value

    - ip rule to lookup custom route table for packets arriving from the pods
    - in the custom route table add route to route traffic to remote node through tunnel interface

Fixes #138
@murali-reddy
Copy link
Member Author

Below testing is done with the patch.

Deployed below cluster, with 2 nodes in us-west-2a, and 2 nodes in us-west-2b so that ip-in-ip tunnelining is in play.

) kops create cluster \
  --node-count 4 \
  --zones us-west-2a,us-west-2b  \
  --master-zones us-west-2a \
  --dns-zone aws.cloudnativelabs.net \
  --node-size t2.medium \
  --master-size t2.medium \
  --networking kube-router \
  --kubernetes-version 1.7.4 \
  --name mycluster.aws.cloudnativelabs.net

Used CentOS AMI so that there is strict reverse path filtering (rp_filter=1).

) kubectl get nodes -o wide
NAME                                          STATUS    AGE       VERSION   EXTERNAL-IP      OS-IMAGE                      KERNEL-VERSION
ip-172-20-36-192.us-west-2.compute.internal   Ready     36s       v1.7.4    52.25.51.111     CentOS Linux 7 (Core)         3.10.0-514.10.2.el7.x86_64
ip-172-20-52-105.us-west-2.compute.internal   Ready     19s       v1.7.4    35.163.93.224    CentOS Linux 7 (Core)         3.10.0-514.10.2.el7.x86_64
ip-172-20-56-101.us-west-2.compute.internal   Ready     2m        v1.7.4    52.10.7.142      Debian GNU/Linux 8 (jessie)   4.4.78-k8s
ip-172-20-69-132.us-west-2.compute.internal   Ready     44s       v1.7.4    35.163.184.220   CentOS Linux 7 (Core)         3.10.0-514.10.2.el7.x86_64
ip-172-20-70-191.us-west-2.compute.internal   Ready     25s       v1.7.4    34.208.205.224   CentOS Linux 7 (Core)         3.10.0-514.10.2.el7.x86_64

Used the test script to deploy 8 instances of gcr.io/google_containers/echoserver:1.4 each of which is exposed as NodePort service.

Test access the node port for each service across all the nodes (40 tests). All passed successfully.

Test covers both scenarios where no tunneling is used, and ip-in-ip tunneling used.

namespace "ipvs" created
deployment "echoheaders0" created
service "echoheaders0" exposed
deployment "echoheaders1" created
service "echoheaders1" exposed
deployment "echoheaders2" created
service "echoheaders2" exposed
deployment "echoheaders3" created
service "echoheaders3" exposed
deployment "echoheaders4" created
service "echoheaders4" exposed
deployment "echoheaders5" created
service "echoheaders5" exposed
deployment "echoheaders6" created
service "echoheaders6" exposed
deployment "echoheaders7" created
service "echoheaders7" exposed
Nodes: ['52.25.51.111', '35.163.93.224', '52.10.7.142', '35.163.184.220', '34.208.205.224']
Node Ports: [30622, 30650, 30903, 31531, 31163, 31691, 32616, 30531]
Node: 52.25.51.111 NodePort: 30622 Response: 200
Node: 52.25.51.111 NodePort: 30650 Response: 200
Node: 52.25.51.111 NodePort: 30903 Response: 200
Node: 52.25.51.111 NodePort: 31531 Response: 200
Node: 52.25.51.111 NodePort: 31163 Response: 200
Node: 52.25.51.111 NodePort: 31691 Response: 200
Node: 52.25.51.111 NodePort: 32616 Response: 200
Node: 52.25.51.111 NodePort: 30531 Response: 200
Node: 35.163.93.224 NodePort: 30622 Response: 200
Node: 35.163.93.224 NodePort: 30650 Response: 200
Node: 35.163.93.224 NodePort: 30903 Response: 200
Node: 35.163.93.224 NodePort: 31531 Response: 200
Node: 35.163.93.224 NodePort: 31163 Response: 200
Node: 35.163.93.224 NodePort: 31691 Response: 200
Node: 35.163.93.224 NodePort: 32616 Response: 200
Node: 35.163.93.224 NodePort: 30531 Response: 200
Node: 52.10.7.142 NodePort: 30622 Response: 200
Node: 52.10.7.142 NodePort: 30650 Response: 200
Node: 52.10.7.142 NodePort: 30903 Response: 200
Node: 52.10.7.142 NodePort: 31531 Response: 200
Node: 52.10.7.142 NodePort: 31163 Response: 200
Node: 52.10.7.142 NodePort: 31691 Response: 200
Node: 52.10.7.142 NodePort: 32616 Response: 200
Node: 52.10.7.142 NodePort: 30531 Response: 200
Node: 35.163.184.220 NodePort: 30622 Response: 200
Node: 35.163.184.220 NodePort: 30650 Response: 200
Node: 35.163.184.220 NodePort: 30903 Response: 200
Node: 35.163.184.220 NodePort: 31531 Response: 200
Node: 35.163.184.220 NodePort: 31163 Response: 200
Node: 35.163.184.220 NodePort: 31691 Response: 200
Node: 35.163.184.220 NodePort: 32616 Response: 200
Node: 35.163.184.220 NodePort: 30531 Response: 200
Node: 34.208.205.224 NodePort: 30622 Response: 200
Node: 34.208.205.224 NodePort: 30650 Response: 200
Node: 34.208.205.224 NodePort: 30903 Response: 200
Node: 34.208.205.224 NodePort: 31531 Response: 200
Node: 34.208.205.224 NodePort: 31163 Response: 200
Node: 34.208.205.224 NodePort: 31691 Response: 200
Node: 34.208.205.224 NodePort: 32616 Response: 200
Node: 34.208.205.224 NodePort: 30531 Response: 200

@murali-reddy murali-reddy merged commit c9c6107 into master Sep 2, 2017
@murali-reddy murali-reddy deleted the pbr_tunnels branch September 2, 2017 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant