and one more thing, why PersistentVolumeClaim could hang in Pending state? I'm using pretty simple config,
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: postgres-pv-claim
labels:
app: postgres
spec:
accessModes:
- ReadWriteOnce resources:
requests:
storage: 5Gi
but the claim is always in Pending
@erulabs @PastuDan Can you fix it ASAP? I have a meeting with my client in 1 hour!
Please let me know if things are working properly for you... sorry again for that outage!
It looks like one of your pods "davidcamelo" is still starting up, that should start any second now.
There we go, just had to wait a second more
Hi @ishumilova - your PVCs should now complete instead of being stuck in pending - we had a brief storage system outage this morning which prevent PVCs from being mounted. All resolved now, and we're working to prevent this going forward!
Hi @progressbarteam - Unfortunately, we currently don't support TCP ingress for free tier users due to some abuse issues we had. Paying users can setup TCP ingress though, and you can also set it up if you attach your own cluster of course. I'd love to get back to offering TCP for free, but it becomes very difficult when people abuse the system :(
On a similar note, you might notice access to, for example, crypto-currency mining pools is forbidden on free tier, for the same reasons :(
@ishumilova Sure - We're working on improving that all the time - there are many manual ways but you can try our Repo Builder tool at https://kubesail.com/repos - it can attach to a GitHub repo and build/push/deploy a Dockerfile image to a KubeSail deployment (including our private registry for image hosting). Hopefully that works for you!
Alternatively, you can always define ImagePullSecrets (https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) to allow KubeSail to pull a private image from any registry (if you wanted to store the image elsewhere).
We absolutely have some work to do to make our UI really nice and friendly to walk thru these steps - for now all the technical tools exist but none of them are obvious or easy to use :( Until then - feel free to ask questions here and we'd be happy to help!
Right now, our repo-builder will see a Dockerfile in your repo and build/push it to a target Deployment. We do plan on supporting proper Skaffold specs soon too - so that you could CI/CD a very complex repo as well - but that's a bit more complex and is still a Coming Soon feature :)
(it's worth nothing in the background, we actually do use skaffold and Kaniko, and we make huge use of Skaffold for our own platform as well - so supporting Skaffold as a first-class-citizen is high on my list - turns out CI/CD systems are fairly complex to design though - so it's taking some time!)
Hi @erulabs , thank you for your help. Actually, it was the first thing I tried to do; so I connected my github repo (which has Dockerfile in the root) to your repo builder tool, but I didn't get any success (it shows me a message ">> Unable to determine what sort of project this is. Please let us know what langauge this project is written in at https://github.com/kubesail/deploy-node-app/issues and we'll add support!"), this is why I have all these questions about the deployment process. Maybe I'm doing something wrong and I should put Dockerfile somewhere else? And is it possible to deploy k8s resources automatically from, for example, k8s directory of my project, when I push a commit to the specific branch?
also, in case of nodejs builds, it overrides my Dockerfile by something that I has never developed:
FROM node:14
# We'll install a few common requirements here - if you have no native modules, you can safely remove the following RUN command
RUN apt-get update && \
apt-get install -yqq nginx automake build-essential curl && \
rm -rf /var/lib/apt/lists/*
USER node
RUN mkdir /home/node/app
WORKDIR /home/node/app
ARG ENV=production
ENV NODE_ENV $ENV
ENV CI=true
COPY --chown=node:node package.json yarn.loc[k] .npmr[c] ./
RUN yarn install
COPY --chown=node:node . .
CMD ["node"]- btw, where can I find a priority support email which is included in the teams tier?
I think the overwriting the dockerfile is a bug - we recently improved the system which tries to guess what your repo is (nodejs, python, etc) and write out a dockerfile if its missing. But it appears to not care if there is already a Dockerfile! It's certainly a bug, we'll try to get that fixed quickly for ya. I sent a private message with our priority support email.
by the way, is it possible to encrypt secrets? :)
Hey @ishumilova - All secrets are encrypted at rest on our side, but you'd need to encrypt the values of the secrets to prevent other apps in your namespace from reading them. Of course you could do this manually, but there are some systems like https://github.com/bitnami-labs/sealed-secrets that are useful - we plan on building a tool to automatically encrypt secrets for each app - but for now you'd have to manually set encrypted values into your secret (and decrypt them in the app).
Hi @erulabs, thanks :) I was actually talking about whether it is possible to configure something like apiserver.config.k8s.io/v1 -> EncryptionConfiguration :)
(it's kinda helpful when I, as a developer, want to store all the infrastructure related files in git, but I don't want to expose the app's secrets)
@ishumilova ah, EncryptionConfiguration is enabled on our cluster. What that does is encrypt your secrets when stored to disk on our servers. But it does not encrypt them on your side, in your YAML files (as you said you would not want to store these in git). For that, I'd suggest something like git-crypt: https://github.com/AGWA/git-crypt
Under https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#verifying-that-data-is-encrypted -> Step 4 notice that the data is decrypted when retrieving it from the API
yup, sorry, it's 8 pm in my time zone, and I'm a little bit tired. I kinda wanted to check whether it's possible to have some kinda extension for encryption on k8s-side for secrets as a customer (and I absolutely forgot that last time I configured the infrastructure, I had it, and this is why my secrets were encrypted by default)
sometimes it's necessary to store k8s configs in git, as well as preventing software engineers from retrieving these secrets (I'm in Germany, so it's about GDPR-related habbits)
unfortunately there's no native way to do that in Kubernetes without additional software