Fix gdb issue and update e2e image

This commit is contained in:
Manuel de Brito Fontes 2018-08-28 22:57:28 -03:00
parent 4019357f2e
commit fdc9ab2158
3 changed files with 84 additions and 80 deletions

View file

@ -40,7 +40,7 @@ if [ "$missing" = true ];then
exit 1 exit 1
fi fi
E2E_IMAGE=quay.io/kubernetes-ingress-controller/e2e:v08252018-3c507e98c E2E_IMAGE=quay.io/kubernetes-ingress-controller/e2e:v08292018-7740d78
DOCKER_OPTS=${DOCKER_OPTS:-""} DOCKER_OPTS=${DOCKER_OPTS:-""}

View file

@ -14,7 +14,8 @@ There are many ways to troubleshoot the ingress-controller. The following are ba
methods to obtain more information. methods to obtain more information.
Check the Ingress Resource Events Check the Ingress Resource Events
```
```console
$ kubectl get ing -n <namespace-of-ingress-resource> $ kubectl get ing -n <namespace-of-ingress-resource>
NAME HOSTS ADDRESS PORTS AGE NAME HOSTS ADDRESS PORTS AGE
cafe-ingress cafe.com 10.0.2.15 80 25s cafe-ingress cafe.com 10.0.2.15 80 25s
@ -27,7 +28,7 @@ Default backend: default-http-backend:80 (172.17.0.5:8080)
Rules: Rules:
Host Path Backends Host Path Backends
---- ---- -------- ---- ---- --------
cafe.com cafe.com
/tea tea-svc:80 (<none>) /tea tea-svc:80 (<none>)
/coffee coffee-svc:80 (<none>) /coffee coffee-svc:80 (<none>)
Annotations: Annotations:
@ -41,7 +42,8 @@ Events:
``` ```
Check the Ingress Controller Logs Check the Ingress Controller Logs
```
```console
$ kubectl get pods -n <namespace-of-ingress-controller> $ kubectl get pods -n <namespace-of-ingress-controller>
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-67956bf89d-fv58j 1/1 Running 0 1m nginx-ingress-controller-67956bf89d-fv58j 1/1 Running 0 1m
@ -57,7 +59,8 @@ NGINX Ingress controller
``` ```
Check the Nginx Configuration Check the Nginx Configuration
```
```console
$ kubectl get pods -n <namespace-of-ingress-controller> $ kubectl get pods -n <namespace-of-ingress-controller>
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-67956bf89d-fv58j 1/1 Running 0 1m nginx-ingress-controller-67956bf89d-fv58j 1/1 Running 0 1m
@ -78,7 +81,8 @@ http {
``` ```
Check if used Services Exist Check if used Services Exist
```
```console
$ kubectl get svc --all-namespaces $ kubectl get svc --all-namespaces
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default coffee-svc ClusterIP 10.106.154.35 <none> 80/TCP 18m default coffee-svc ClusterIP 10.106.154.35 <none> 80/TCP 18m
@ -94,7 +98,7 @@ kube-system kubernetes-dashboard NodePort 10.103.128.17 <none>
Using the flag `--v=XX` it is possible to increase the level of logging. This is performed by editing Using the flag `--v=XX` it is possible to increase the level of logging. This is performed by editing
the deployment. the deployment.
``` ```console
$ kubectl get deploy -n <namespace-of-ingress-controller> $ kubectl get deploy -n <namespace-of-ingress-controller>
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
default-http-backend 1 1 1 1 35m default-http-backend 1 1 1 1 35m
@ -122,25 +126,24 @@ Both authentications must work:
+ apiserver +<-------------------+ ingress | + apiserver +<-------------------+ ingress |
| | | controller | | | | controller |
+-------------+ +------------+ +-------------+ +------------+
``` ```
__Service authentication__ **Service authentication**
The Ingress controller needs information from apiserver. Therefore, authentication is required, which can be achieved in two different ways: The Ingress controller needs information from apiserver. Therefore, authentication is required, which can be achieved in two different ways:
1. _Service Account:_ This is recommended, because nothing has to be configured. The Ingress controller will use information provided by the system to communicate with the API server. See 'Service Account' section for details. 1. _Service Account:_ This is recommended, because nothing has to be configured. The Ingress controller will use information provided by the system to communicate with the API server. See 'Service Account' section for details.
2. _Kubeconfig file:_ In some Kubernetes environments service accounts are not available. In this case a manual configuration is required. The Ingress controller binary can be started with the `--kubeconfig` flag. The value of the flag is a path to a file specifying how to connect to the API server. Using the `--kubeconfig` does not requires the flag `--apiserver-host`. 2. _Kubeconfig file:_ In some Kubernetes environments service accounts are not available. In this case a manual configuration is required. The Ingress controller binary can be started with the `--kubeconfig` flag. The value of the flag is a path to a file specifying how to connect to the API server. Using the `--kubeconfig` does not requires the flag `--apiserver-host`.
The format of the file is identical to `~/.kube/config` which is used by kubectl to connect to the API server. See 'kubeconfig' section for details. The format of the file is identical to `~/.kube/config` which is used by kubectl to connect to the API server. See 'kubeconfig' section for details.
3. _Using the flag `--apiserver-host`:_ Using this flag `--apiserver-host=http://localhost:8080` it is possible to specify an unsecured API server or reach a remote kubernetes cluster using [kubectl proxy](https://kubernetes.io/docs/user-guide/kubectl/kubectl_proxy/). 3. _Using the flag `--apiserver-host`:_ Using this flag `--apiserver-host=http://localhost:8080` it is possible to specify an unsecured API server or reach a remote kubernetes cluster using [kubectl proxy](https://kubernetes.io/docs/user-guide/kubectl/kubectl_proxy/).
Please do not use this approach in production. Please do not use this approach in production.
In the diagram below you can see the full authentication flow with all options, starting with the browser In the diagram below you can see the full authentication flow with all options, starting with the browser
on the lower left hand side. on the lower left hand side.
```
```
Kubernetes Workstation Kubernetes Workstation
+---------------------------------------------------+ +------------------+ +---------------------------------------------------+ +------------------+
| | | | | | | |
@ -168,7 +171,7 @@ token that is required to authenticate with the API server.
Verify with the following commands: Verify with the following commands:
```shell ```console
# start a container that contains curl # start a container that contains curl
$ kubectl run test --image=tutum/curl -- sleep 10000 $ kubectl run test --image=tutum/curl -- sleep 10000
@ -237,23 +240,23 @@ $ kubectl exec test-701078429-s5kca -- curl --cacert /var/run/secrets/kubernetes
If it is not working, there are two possible reasons: If it is not working, there are two possible reasons:
1. The contents of the tokens are invalid. Find the secret name with `kubectl get secrets | grep service-account` and 1. The contents of the tokens are invalid. Find the secret name with `kubectl get secrets | grep service-account` and
delete it with `kubectl delete secret <name>`. It will automatically be recreated. delete it with `kubectl delete secret <name>`. It will automatically be recreated.
2. You have a non-standard Kubernetes installation and the file containing the token may not be present. 2. You have a non-standard Kubernetes installation and the file containing the token may not be present.
The API server will mount a volume containing this file, but only if the API server is configured to use The API server will mount a volume containing this file, but only if the API server is configured to use
the ServiceAccount admission controller. the ServiceAccount admission controller.
If you experience this error, verify that your API server is using the ServiceAccount admission controller. If you experience this error, verify that your API server is using the ServiceAccount admission controller.
If you are configuring the API server by hand, you can set this with the `--admission-control` parameter. If you are configuring the API server by hand, you can set this with the `--admission-control` parameter.
> Note that you should use other admission controllers as well. Before configuring this option, you should read about admission controllers. > Note that you should use other admission controllers as well. Before configuring this option, you should read about admission controllers.
More information: More information:
* [User Guide: Service Accounts](http://kubernetes.io/docs/user-guide/service-accounts/) - [User Guide: Service Accounts](http://kubernetes.io/docs/user-guide/service-accounts/)
* [Cluster Administrator Guide: Managing Service Accounts](http://kubernetes.io/docs/admin/service-accounts-admin/) - [Cluster Administrator Guide: Managing Service Accounts](http://kubernetes.io/docs/admin/service-accounts-admin/)
## Kube-Config ## Kube-Config
If you want to use a kubeconfig file for authentication, follow the [deploy procedure](../docs/deploy/index.md) and If you want to use a kubeconfig file for authentication, follow the [deploy procedure](../docs/deploy/index.md) and
add the flag `--kubeconfig=/etc/kubernetes/kubeconfig.yaml` to the args section of the deployment. add the flag `--kubeconfig=/etc/kubernetes/kubeconfig.yaml` to the args section of the deployment.
## Using GDB with Nginx ## Using GDB with Nginx
@ -261,74 +264,76 @@ add the flag `--kubeconfig=/etc/kubernetes/kubeconfig.yaml` to the args section
[Gdb](https://www.gnu.org/software/gdb/) can be used to with nginx to perform a configuration [Gdb](https://www.gnu.org/software/gdb/) can be used to with nginx to perform a configuration
dump. This allows us to see which configuration is being used, as well as older configurations. dump. This allows us to see which configuration is being used, as well as older configurations.
Before starting make sure that nginx is running with the `--with-debug`. See the `Debug Logging` section seen above.
Note: The below is based on the nginx [documentation](https://docs.nginx.com/nginx/admin-guide/monitoring/debugging/#dumping-nginx-configuration-from-a-running-process). Note: The below is based on the nginx [documentation](https://docs.nginx.com/nginx/admin-guide/monitoring/debugging/#dumping-nginx-configuration-from-a-running-process).
1. SSH into the worker 1. SSH into the worker
```
$ ssh user@workerIP ```console
``` $ ssh user@workerIP
```
2. Obtain the Docker Container Running nginx 2. Obtain the Docker Container Running nginx
```
$ docker ps | grep nginx-ingress-controller ```console
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES $ docker ps | grep nginx-ingress-controller
d9e1d243156a quay.io/kubernetes-ingress-controller/nginx-ingress-controller "/usr/bin/dumb-init …" 19 minutes ago Up 19 minutes k8s_nginx-ingress-controller_nginx-ingress-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
``` d9e1d243156a quay.io/kubernetes-ingress-controller/nginx-ingress-controller "/usr/bin/dumb-init …" 19 minutes ago Up 19 minutes k8s_nginx-ingress-controller_nginx-ingress-controller-67956bf89d-mqxzt_kube-system_079f31ec-aa37-11e8-ad39-080027a227db_0
```
3. Exec into the container 3. Exec into the container
```
$ docker exec -it --user=0 --privileged d9e1d243156a bash
```
4. Make sure nginx is running in `--with-debug`
```
$ nginx -V 2>&1 | grep -- '--with-debug'
```
5. Install gdb
```
$ apt-get update; apt-get install gdb -y
```
6. Get list of processes running on container ```console
``` $ docker exec -it --user=0 --privileged d9e1d243156a bash
$ ps -ef ```
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 20:23 ? 00:00:00 /usr/bin/dumb-init /nginx-ingres 4. Make sure nginx is running in `--with-debug`
root 5 1 0 20:23 ? 00:00:05 /nginx-ingress-controller --defa
root 21 5 0 20:23 ? 00:00:00 nginx: master process /usr/sbin/ ```console
nobody 106 21 0 20:23 ? 00:00:00 nginx: worker process $ nginx -V 2>&1 | grep -- '--with-debug'
nobody 107 21 0 20:23 ? 00:00:00 nginx: worker process ```
root 172 0 0 20:43 pts/0 00:00:00 bash
``` 5. Get list of processes running on container
```console
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 20:23 ? 00:00:00 /usr/bin/dumb-init /nginx-ingres
root 5 1 0 20:23 ? 00:00:05 /nginx-ingress-controller --defa
root 21 5 0 20:23 ? 00:00:00 nginx: master process /usr/sbin/
nobody 106 21 0 20:23 ? 00:00:00 nginx: worker process
nobody 107 21 0 20:23 ? 00:00:00 nginx: worker process
root 172 0 0 20:43 pts/0 00:00:00 bash
```
7. Attach gdb to the nginx master process 7. Attach gdb to the nginx master process
```
$ gdb -p 21 ```console
.... $ gdb -p 21
Attaching to process 21 ....
Reading symbols from /usr/sbin/nginx...done. Attaching to process 21
.... Reading symbols from /usr/sbin/nginx...done.
(gdb) ....
``` (gdb)
```
8. Copy and paste the following: 8. Copy and paste the following:
```
set $cd = ngx_cycle->config_dump ```console
set $nelts = $cd.nelts set $cd = ngx_cycle->config_dump
set $elts = (ngx_conf_dump_t*)($cd.elts) set $nelts = $cd.nelts
while ($nelts-- > 0) set $elts = (ngx_conf_dump_t*)($cd.elts)
set $name = $elts[$nelts]->name.data while ($nelts-- > 0)
printf "Dumping %s to nginx_conf.txt\n", $name set $name = $elts[$nelts]->name.data
append memory nginx_conf.txt \ printf "Dumping %s to nginx_conf.txt\n", $name
$elts[$nelts]->buffer.start $elts[$nelts]->buffer.end append memory nginx_conf.txt \
end $elts[$nelts]->buffer.start $elts[$nelts]->buffer.end
``` end
```
9. Quit GDB by pressing CTRL+D 9. Quit GDB by pressing CTRL+D
10. Open nginx_conf.txt 10. Open nginx_conf.txt
```
cat nginx_conf.txt ```console
``` cat nginx_conf.txt
```

View file

@ -541,7 +541,6 @@ apt-get remove -y --purge \
protobuf-compiler \ protobuf-compiler \
python \ python \
xz-utils \ xz-utils \
libpython3.6-stdlib \
git g++ pkgconf flex bison doxygen libyajl-dev liblmdb-dev libgeoip-dev libtool dh-autoreconf libpcre++-dev libxml2-dev git g++ pkgconf flex bison doxygen libyajl-dev liblmdb-dev libgeoip-dev libtool dh-autoreconf libpcre++-dev libxml2-dev
apt-get autoremove -y apt-get autoremove -y