The treatment of the subject is a bit high level with focus on what resources and fields are relevant and on the way different Kubernetes resources relate to each other. Also some snippets of YAML configuration are given. This should be sufficient to ‘roll your own’.<\/p>\n
<\/p>\n
Deploying services in different namespaces<\/h2>\n
The basic architecture we start off with is as follows:<\/p>\n
\nhide circle
\nclass Ingress {
\nnamespace
\n}
\nclass Service {
\nnamespace
\n}
\nclass Deployment {
\nnamespace
\n}<\/p>\n
Ingress –> “*” Service
\nService –> “1” Deployment<\/p>\n
\" usemap=\"#plantuml_map\"><\/p>\n
In this basic setup,\u00a0 there is one Ingress object in a certain namespace and each Service that it exposes is in a separate namespace together with its deployment. There is a limitation in Ingress that does not allow it to be used when Services are in a different namespace than the Ingress resource. This limitation is expected to be lifted in a future version of Kubernetes using the Gateway API<\/a>.<\/p>\n One workaround is to deploy a separate Ingress in every Service namespace. However, this leads to other problems since than separate IPs must be used for each service. On apache, this can be a configuration such as this: The architecture for two services resp. x in namespace y<\/em> and x2<\/em> in namespace y2<\/em> then becomes:<\/p>\n \" usemap=\"#plantuml_map\"><\/p>\n This architecture is quite flexible. It allows SSL termination on a using a single Ingress rule and provides complete flexibility in allocating services to namespaces.<\/p>\n The apache deployment is configured using a config map that contains the httpd.conf file in a ConfigMap <\/em>resource.\u00a0The ConfigMap<\/em> is mounted into the pod as follows:<\/p>\n Note the use of the subPath<\/em>\u00a0configuration in the deployment spec to mount only a single file from the httpd-conf volume, which keeps all other files in the \/usr\/local\/apache2\/conf\/<\/em> directory intact. The config map can be created from an existing httpd.conf file as follows:<\/p>\n The httpd.conf<\/em> used is an adaptation of the file that comes standard with the container. Since we are terminating SSL using Ingress<\/em>, the httpd config is without any SSL configuration or reference to certificate files.<\/p>\n To expose the httpd service externally (and thereby all services for which it is a reverse proxy), we need to introduce the FrontendConfig<\/a><\/em> resource. The FrontendConfig<\/em> is a custom resource that is only available on GKE as far as I know and this is used to configure Ingress features.The SSL Policy is a GCP object that defines SSL features for the HTTPS connection.<\/p>\n expose -right-> frontend Using this setup, we can configure:<\/p>\n It is most easy to look at the Ingress configuration:<\/p>\n First of all, we see that all traffic is forwarded to httpd, which is ok since httpd distributes the traffic over backend services and as far as Ingress just routes to httpd. Next, we see several other features.<\/p>\n The annotation kubernetes.io\/ingress.allow-http<\/em> can be used to disable http but this is commented out since we allow http and will do a redirect to https instead using the FrontendConfig<\/em>.<\/p>\n Next, the annotation kubernetes.io\/ingress.global-static-ip-name<\/em> defines the name of a previously created static IP address in GCP which is the static IP address under which the services are exposed.<\/p>\n The annotation ingress.gcp.kubernetes.io\/pre-shared-cert<\/em> defines the name of the pre-shared certificate that is used.<\/p>\n A pre-shared certificate is a certificate registered at GCP. Based on the domain name, GCP automatically chooses the certificate. This means that explicit configuration of the certificate using the tls<\/em> section is not needed and this part is therefore commented out. It also allows the same certificate to be used by multiple GKE clusters and is thus lower maintenance than using the alternative setup by defining a secret per GKE cluster for the certificates.<\/p>\n To create the pre-shared certificate, concatenate the crt files of the certificate containing the certificate and certificate chain and put it into a single file as follows:<\/p>\n Next, create the pre-shared certificate from this file and the private key file:<\/p>\n The final part is the networking.gke.io\/v1beta1.FrontendConfig<\/em> annotation which links the ingress resource to the frontend config.<\/p>\n The FrontendConfig<\/em>, finally, is as follows:<\/p>\n In this configuration we see that the redirect from http to https is configured. Also, there is reference to an SSL policy<\/a> which defines SSL features. For instance:<\/p>\n This post explains how to host services on Google Compute Engine, parts of this are applicable to regular (non-GKE) Kubernetes clusters as well. This post will cover: allowing multiple services to be deployed in different namespaces allowing multiple (sub)domains to … Continue reading
\nA better solution is to use a separate ingress namespace in which to deploy a reverse proxy (in the example httpd is used, but nginx is of course also possible) and from there to setup a reverse proxy using the cluster local DNS name for the service. Given that a service x<\/em> is deployed in namespace y<\/em>, it can be accessed using the DNS name x.y.svc.cluster.local<\/em>.<\/p>\n
\n
\nProxyPass \/hello http:\/\/X.Y.svc.cluster.local\/hello
\nProxyPassReverse \/hello http:\/\/X.Y.svc.cluster.local\/jenkins
\n<\/code><\/p>\n\npackage “namespace: exposure” {
\nobject “expose:Ingress” as expose
\nobject “httpd:Service” as httpdservice
\nobject “httpd:Deployment” as httpddeploy
\nobject “httpd-config:ConfigMap” as httpdconfig
\n}
\npackage “namespace: y” {
\nobject “x:Service” as xservice
\nobject “x:Deployment” as xdeploy
\n}
\npackage “namespace: x2” {
\nobject “x2:Service” as x2service
\nobject “x2:Deployment” as x2deploy
\n}
\nexpose –> httpdservice
\nhttpdservice -> httpddeploy
\nhttpddeploy “\\nx.y.svc.cluster.local” –> xservice
\nhttpddeploy -> httpdconfig
\nxservice -> xdeploy
\nhttpddeploy “\\nx2.y2.svc.cluster.local” –> x2service
\nx2service -> x2deploy<\/p>\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: httpd\n namespace: exposure\n ...\nspec:\n ...\n template:\n ...\n spec:\n containers:\n - name: httpd\n image: httpd:2.4\n ...\n volumeMounts:\n - name: httpd-conf\n mountPath: \/usr\/local\/apache2\/conf\/httpd.conf\n subPath: httpd.conf\n volumes:\n - name: httpd-conf\n configMap: \n name: httpd-config\n<\/pre>\n
kubectl create configmap --namespace exposure \\\n httpd-config --from-file=httpd.conf\n<\/pre>\n
Exposing the service externally<\/h2>\n
\npackage “Kubernetes” {
\nobject “expose:Ingress” as expose
\nobject “frontendconfig:FrontendConfig” as frontend
\n}
\npackage “GCP” {
\nobject “gke-ingress-ssl-policy:SSLPolicy” as policy
\nobject “example-ip:IpAddress” as ipaddress
\nobject “example-com:PreSharedCertificate” as certificate
\n}<\/p>\n
\nfrontend -down-> policy
\nexpose -down-> ipaddress
\nexpose -down-> certificate
\n\" usemap=\"#plantuml_map\"><\/p>\n\n
apiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: httpd-ingress\n annotations:\n #kubernetes.io\/ingress.allow-http: \"false\"\n kubernetes.io\/ingress.global-static-ip-name: example-ip\n ingress.gcp.kubernetes.io\/pre-shared-cert: example-com\n networking.gke.io\/v1beta1.FrontendConfig: frontendconfig\n namespace: exposure\nspec:\n # tls config not needed since a pre-shared certificate\n # is used. \n #tls:\n # - hosts:\n # - example.com\n # secretName: example-com-certificates\n\n rules:\n - host: example.com\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: httpd\n port:\n number: 80\n\n<\/pre>\n
cat example.com.crt example.com.2022.crt > full.crt\n<\/pre>\n
gcloud compute ssl-certificates create example-com \\\n --project example-project \\\n --global \\\n --certificate=full.crt \\\n --private-key=example_2022.key\n<\/pre>\n
apiVersion: networking.gke.io\/v1beta1\nkind: FrontendConfig\nmetadata:\n name: frontendconfig\n namespace: exposure\nspec:\n redirectToHttps:\n enabled: true\n sslPolicy: gke-ingress-ssl-policy\n<\/pre>\n
gcloud compute ssl-policies create gke-ingress-ssl-policy \\\n --profile MODERN \\\n --min-tls-version 1.2\n<\/pre>\n","protected":false},"excerpt":{"rendered":"