1

I try to configure Google Cloud CDN to my container engine project.

Following the documentation It has either a Content-Length header or a Transfer-Encoding header in order to be cached.

My backend use gzip compression so I have Transfer-Encoding: chunked

The problem is it seems the ingress load balancer remove the Transfer-encoding header so I can't have a "cache hit"

I used "kubectl port-forward" to connect direclty to an instance backend and I have the Transfer-encoding header.

But when I connect to the external IP, the header has disappear.

Here my ingress configuration

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gateway-preprod3-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: gateway-preprod2-static-ip
spec:
  tls:
  - secretName: gateway-preprod-secret-2018-with-ca-7
  backend:
    serviceName: gateway-preprod
    servicePort: 80

Here my deployment configuration

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: gateway-preprod
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  minReadySeconds: 50
  template:
    metadata:
      labels:
        app: gateway-preprod
    spec:
      containers:
      - name: gateway-preprod
        image: eu.gcr.io/writecontrol-1055/gateway:v305
        env:
        - name: writecontrolEnv
          value: preprod
        ports:
        - containerPort: 80

In the opposite, for certain ressources not GZIP compressed, the Content-length header is given and I have a successful "cache hit"

The kubernetes version is 1.7.12-gke.1

Here an URL to test it : https://preprod-writecontrol.ovh

maxiplay
  • 427
  • 1
  • 5
  • 13
  • Which documents you are using to deploy your CDN over GKE?. What's the exact request you are using to test the CDN?. Additionally, you need to check [this](https://cloud.google.com/compute/docs/load-balancing/http/#illegal_request_handling) documentation on 'Ilegal request handling', where it explains a number of reasons for a LB blocks the client request from reaching the back-end. – Digil Mar 16 '18 at 23:26
  • All static resources can be tested : for example https://preprod-writecontrol.ovh/bower_components/webcomponentsjs/webcomponents-lite.min.js I have response for load balancer . The problem is I don't have a header that my backend sent => Transfer-encoding – maxiplay Mar 17 '18 at 12:56
  • Can you provide me the documents which I have requested in my previous message ? This would help me to reproduce the issue. Additionally, you might need to check [this](https://cloud.google.com/cdn/docs/support) basic troubleshooting guide for common Cloud CDN problems. See if that helps you as well. – Digil Mar 18 '18 at 22:18
  • I don't understand your question. You speak about documentation ? Here it is https://cloud.google.com/cdn/docs/caching Or you speak about the cdn configuration ? I use the Default I already check the documentation https://cloud.google.com/cdn/docs/support – maxiplay Mar 19 '18 at 20:37
  • And I can have cache hit succes for certain request that have content-length header, so my cdn cache configuration seels good. But if the request has no content-length but have Transfer-encoding from backend there is no cache hit and no Transfer-encoding header in LB response – maxiplay Mar 19 '18 at 20:44
  • If I deactivate GZIP compression from my backend, i have content-lenght header so I can have cache hit success. But no cache hit when GZIP activated, I think that because I don't have content-lenght header. l have Transfer-encoding header sent by backend but it seems the LB don't transfer this Transfer-encoding header to the Google Cloud CDN – maxiplay Mar 19 '18 at 20:54
  • https://github.com/kubernetes/ingress-gce/issues/157 – maxiplay Mar 19 '18 at 22:20
  • 1
    I could not reproduce this issue. It looks like you have already checked [this](https://cloud.google.com/cdn/docs/support#low-hit-rate) documentation where they have mentioned possible causes for 'Compression isn't working'. At this point, if the issue still persists on your end, I suggest you to open a defect report via this [issue tracker](https://cloud.google.com/support/docs/issue-trackers) – Digil Mar 22 '18 at 00:04

1 Answers1

2

I am not sure why your response has Transfer-Encoding header. This header is not meant to be at the source (your application) and it is usually added by other hops, such as proxies like Cloud HTTP Load Balancer (=Ingress).

More info on Transfer-Encoding here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding


I was able to get CDN working with a GZIP response myself using the Content-Encoding header instead:

First read the caching requirements at https://cloud.google.com/cdn/docs/caching. You need a Content-Length and/or Cache-Control: public header. So code these headers into your application server.

After enabling CDN on the load balancer created by Ingress, make two requests, and if you see Age header on the second request (as I did below), it means your request is now being served from CDN.

curl -vH Accept-Encoding:gzip 35.186.195.233
> [...]
>
< HTTP/1.1 200 OK
< Content-Encoding: gzip
< Date: Tue, 27 Mar 2018 19:38:20 GMT
< Content-Length: 87
< Content-Type: application/x-gzip
< Via: 1.1 google
< Cache-Control: max-age=600,public

��H����Q(�/�IQ�
* Connection #0 to host 35.186.195.233 left intact
K-*��ϳR0�3�3���/.�K�M�R�)+OM�55575��L�4ѭ�N+L���K��4A

And the second request (note the Age header):

$ curl -vH Accept-Encoding:gzip 35.186.195.233
[...]
>
< HTTP/1.1 200 OK
< Cache-Control: max-age=600,public
< Content-Encoding: gzip
< Date: Tue, 27 Mar 2018 19:42:01 GMT
< Content-Length: 87
< Content-Type: application/x-gzip
< Via: 1.1 google
< Age: 314
<
��H����Q(�/�IQ�
* Connection #0 to host 35.186.195.233 left intact
K-*��ϳR0�3�3���/.�K�M�R�)+OM�55575��L�4ѭ�N+L���K��4A
ahmet alp balkan
  • 42,679
  • 38
  • 138
  • 214
  • 1
    Doing this will have measurable performance negatives for large transfers, because the entire source will have to be compressed before the first byte is sent. The usage of "Transfer-Encoding : chunked" is quite common for servers that streams data. I'm using java spring boot application server that by default use "Transfer-encoding : chunked" when using GZIP. It's seems that it's a standard. Even nginx use it. https://en.wikipedia.org/wiki/Chunked_transfer_encoding – maxiplay Mar 28 '18 at 08:31
  • 1
    An other example with Apache http server. Apache uses chunked encoding only if the compressed file size is larger than the DeflateBufferSize. Increasing this buffer size will therefore prevent the server using chunked encoding also for larger files, causing the Content-Length to be sent even for zipped data. More Information is available here: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#deflatebuffersize – maxiplay Mar 28 '18 at 08:33
  • Following the Google Cloud CDN documentation, the transfer-encoding can be used instead of content-length "The status code was 200, 203, 300, 301, 302, 307, or 410. It has either a Content-Length header or a Transfer-Encoding header." – maxiplay Mar 28 '18 at 08:36
  • 2
    Sorry I was not aware. My exposure to Transfer-Encoding is limited. Consider filing a bug for Load Balancer (not GKE) in Google Cloud’s public issue trackers. – ahmet alp balkan Mar 29 '18 at 18:06