You are given a restricted access to the Kubernetes API of a cluster. You can run your pods the same way you are used to (i.e.: with Deployments and Services); however, in order to keep all our customers secure, our clusters are using a Pod Security Admission.
We enforce the Restricted Pod Security Standard on all pods.
This basically means that all containers must run as non-root and neither capabilities nor privilege escalations can be granted (see here for more information about the restrictions of this particular Pod Security Standard).
By default, all namespaces (and pods within) are hermetic to exterior sollicitations (be it the Internet or another customer's namespace in the same cluster). If you want your pods to be available from outside your namespace, you have to configure a NetworkPolicy.
We provide a way for your pods to be reached from the Internet via HTTP(S): our cluster's loadbalancers will serve incoming traffic to your namespaces.
The URL on which a namespace is available is: <namespace>.<cluster>.cheapernetes.com.
For example, if you have a namespace called u012345678-myapp on gra5-alpha, the URL on which your app is available will be:
https://u012345678-myapp.gra5-alpha.cheapernetes.com.
However, for our loadbalancers to know where to send the traffic, you have to declare a Service called web-traffic.
Here are the templates for the aforementioned Service and NetworkPolicy:
---
apiVersion: v1
kind: Service
metadata:
name: web-traffic
namespace: <your namespace>
spec:
selector:
<configure depending on your pods>
ports:
- protocol: TCP
port: 80
targetPort: <configure depending on your pods>
name: http---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: <whatever your want>
namespace: <your namespace>
spec:
# Configure depending on your needs; all pods in this case
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
"kubernetes.io/metadata.name": loadbalancer
ports:
- protocol: TCP
port: 80Once these are applied, your pods will become reachable in a matter of seconds. The URL on where to reach them is the little link icon next to your namespace name.
Your quota is what allows Kubernetes to run your workload.
Your quota is the amount of resources you are allowed to use in the cluster. You configure resources on your pods, and depending on the amount of quota you purchased, pods will be allowed to run or not. See here for more information about resource management.
You can manage your quota on your dashboard (you can both tweak the amount of resources you need and the duration).
Note that you can ask for the CPU limit to be at most 4 times the CPU request and the RAM limit to be at most 2 times the RAM request. If you don't provide any request or limit to your pods, we will automatically assign the smallest possible requests to your containers (which is 0.05 CPU and 64 MiB of RAM).
It will automatically be set to 0.
When your quota decreases (either because you asked for it or because it has expired), we will check if your running workloads are within the new quota. If you exceed your new quota, we will kill and remove all your pods. Your deployments / replicasets might then re-schedule new pods depending on your new quota and your pods' resources requests, as expected.
If you want to scale down your quota and don't want downtime, you have to change your containers' resources requests before changing your quota.
Our Kubernetes APIs are available according to this pattern (depending on the cluster):
https://<cluster>.cheapernetes.com:6443
You don't have to remember this as these URLs are already populated in the .kube/config file that you can download from your dashboard.
However, Kubernetes won't allow just anybody to connect to its API. For you to be able to use the API, you have to create an identity in your dashboard. An identity is tied to an account and to a cluster. You can have multiple different identities per cluster and you can create the same identity in multiple clusters. Identities are basically public keys (that you own) which are signed (= trusted) by our Kubernetes clusters.
Every identity has full access to all your namespaces in the selected cluster. When an identity expires (or when you revoke it from your account), it is no longer usable in the cluster it has been linked to.
As we explained in the How to route traffic from the Web to my app? section, for every namespace you have, we provide a generic domain for it to be reachable from the internet. This generic domain has the following pattern:
https://<namespace>.<cluster>.cheapernetes.com
We provide this domain for free so that you can test your application easily. However, you might want to use a more personal domain for applications that are client-facing.
You can add domains (or subdomains) that you control on your dashboard. For every domain that you add, we provide you with a TXT record to set in your domain's DNS (so that we can make sure that you actually have control of the domain). Once the TXT record is added, our bots will validate the domain and mark it as validated on your dashboard (it means that it will be served by our infrastructure). In the meantime, you are able to link the domain with a namespace (which means that all traffic targeting the given domain reaching our infrastructure will be forwarded to the given namespace).
We do not provide TLS certificates for custom domains; however, we give you a way to provide us with your certificate in a similar way Web traffic is routed to your app: you have to create a Secret called web-traffic, in which each key would be a domain name and each value the associated bundle of private key, certificate and certificate chain. For example:
---
apiVersion: v1
kind: Secret
metadata:
name: web-traffic
namespace: <your namespace>
type: Opaque
data:
mydomain.com: <base64-encoded key + certificates bundle>
otherdomain.org: <base64-encoded key + certificates bundle>
You can have a pod running Certbot to generate certificates from Let's Encrypt and have a hook pushing the bundle to the Secret. You can also have a classic (= manual) certificate that you push manually to the Secret. It's up to you.
Important note: for your certificate to be used by our infrastructure, the associated domain (in the
CN field) must be created and validated in your dashboard. If you have
multiple domains / subdomains in your certificate (i.e.: with the SAN
field), all domains / subdomains must be created and validated in your dashboard. If any domain is not
declared or not validated, the certificate won't be used (if it is already being used, it will be removed from our
loadbalancers - in this case, first remove the domain from the certificate and then remove it from your dashboard).
This means wildcards in certificates are not supported.