Start local proxy
Start proxy and accept all hosts
kubectl proxy --address=localhost --accept-hosts=^.*$
Allow access to the API server from outside
kubectl proxy --address=192.168.1.110 --port=8003 --accept-hosts=^.*$
Helper Commands
Copy secrets from one namespace to another
kubectl get secret <secret_name> -n <source_namespace> -o yaml | sed 's/namespace: <source_namespace>/namespace: <destination_namespace>/g' | kubectl apply -f -
API definitions
Pod manipulation
Open shell in the pod
Copy from/to the pod
If you're using Kubernetes and you want to copy files from a Pod, you can use the kubectl cp command. The syntax is as follows:
kubectl cp <namespace>/<pod-name>:<pod-path> <local-path>
Here's how you can interpret the command:
<namespace>
: This is the Kubernetes namespace where your Pod is running. If you don't specify a namespace, the default namespace is used.<pod-name>
: This is the name of the Pod from which you want to copy files.<pod-path>
: This is the absolute path of the file or directory inside the Pod that you want to copy.<local-path>
: This is the path on your local machine where you want to copy the file to.
Example
kubectl cp default/my-pod:/var/log/mylog.log ~/Desktop/
If your pod has multiple containers, you'll need to specify which container you're copying files from. You can use the -c or --container option followed by the container name.
kubectl cp <namespace>/<pod-name>:<pod-path> <local-path> -c <container-name>
See pod stdout stdout
Follow pod stdout
Ingress Traefik
API
Middleware
- List/Create
/apis/traefik.containo.us/v1alpha1/namespaces/{namespace}/middlewares
- Get/Delete
/apis/traefik.containo.us/v1alpha1/namespaces/{namespace}/middlewares/{name}
Assign middleware to an ingress
INFO
Multiple middlewares can be assigned ,
separated. Order matters.
format: <namespace_name>-<middleware_name>@kubernetescrd
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.class: "traefik"
traefik.ingress.kubernetes.io/router.middlewares: "default-stripprefix@kubernetescrd, default-stripprefix2@kubernetescrd"
Ingress nginx
Typical Ingress route
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: example.com
http:
paths:
- pathType: Prefix
path: /test(/|$)(.*)
backend:
service:
name: demo
port:
number: 80
In this example, any traffic coming to example.com/test
will be routed to the demo
service at port 80
. The nginx.ingress.kubernetes.io/rewrite-target
annotation is used to strip the path prefix /test
. The /(|$)(.*)
regular expression captures anything after /test (if anything exists) and uses it in the rewrite target.
Usage of sub_filter
Nginx Ingress allows you to use the sub_filter
directive, which replaces one specified string with another. You can use the nginx.ingress.kubernetes.io/configuration-snippet
annotation to include raw Nginx configuration.
Here's an example:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
sub_filter 'originalString' 'newString';
sub_filter_once off;
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: example.com
http:
paths:
- pathType: Prefix
path: /test(/|$)(.*)
backend:
service:
name: demo
port:
number: 80
In this example, originalString
will be replaced with newString
in the HTTP response. The sub_filter_once off;
directive is used to replace all occurrences of the specified string, not just the first one.
This is a useful feature when you need to adjust the content of the HTTP response before sending it back to the client.
Please note that this is an advanced feature and it should be used cautiously. Incorrect usage might break your application or introduce security vulnerabilities.
Nginx ingress annotations
Nginx Ingress controller has several annotations that you can use to customize its behavior. Here are some examples:
nginx.ingress.kubernetes.io/rewrite-target
: Changes the URL that is passed to the service.nginx.ingress.kubernetes.io/ssl-redirect
: Controls whether to redirect HTTP clients to HTTPS.nginx.ingress.kubernetes.io/add-base-url
: Modifies the response from the backend service.nginx.ingress.kubernetes.io/default-backend
: Specifies the backend to use when none match.nginx.ingress.kubernetes.io/force-ssl-redirect
: Forces SSL redirection regardless of the Ingress SSL setting.nginx.ingress.kubernetes.io/from-to-www-redirect
: Redirects traffic from non-www to www.nginx.ingress.kubernetes.io/server-snippet
: Adds custom Nginx configuration.nginx.ingress.kubernetes.io/configuration-snippet
: Adds custom Nginx configuration on a location basis.nginx.ingress.kubernetes.io/affinity
: Controls session affinity.nginx.ingress.kubernetes.io/session-cookie-name
: Sets the name of the affinity cookie.nginx.ingress.kubernetes.io/session-cookie-expires
: Sets the affinity cookie expiration time.nginx.ingress.kubernetes.io/session-cookie-max-age
: Sets the maximum age of the affinity cookie.nginx.ingress.kubernetes.io/session-cookie-change-on-failure
: Changes the affinity cookie when the endpoint fails.nginx.ingress.kubernetes.io/enable-cors
: Enables or disables cross-origin resource sharing (CORS).nginx.ingress.kubernetes.io/cors-allow-methods
: Sets the allowed methods in the CORS header.nginx.ingress.kubernetes.io/cors-allow-headers
: Sets the allowed headers in the CORS header.nginx.ingress.kubernetes.io/cors-allow-credentials
: Sets the Access-Control-Allow-Credentials CORS header.
Nginx ingres proxy
There are annotations specifically for WebSockets in Nginx Ingress. WebSockets are a protocol providing full-duplex communication channels over a single TCP connection.
When working with WebSockets, the Nginx Ingress Controller has support for WebSockets out of the box without needing to add any specific annotations. This means that by default, you should be able to use WebSockets without any additional configuration.
However, if you are running into any issues or you are using a long-lived connection, you may need to tweak some settings via annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout
: This changes the timeout of reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed. It's measured in seconds with a default of 60s. For WebSocket connections or long polling, you might need to increase this and the next timeout.nginx.ingress.kubernetes.io/proxy-send-timeout
: This sets the timeout for transmitting a request to the proxied server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the proxied server does not receive anything within this time, the connection is closed.
Here is an example of how you might use these:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ws-ingress
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
spec:
rules:
- host: ws.example.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: ws-service
port:
number: 80
In this example, both the read and send timeouts are set to 3600 seconds (1 hour), which might be useful for long-lived WebSocket connections or other situations where connections need to stay open for a long time.