Loo kontoLogi sisse

Viimatised otsingud

Pole viimatisi otsinguid

Otsimisvalikud

Saadaval vaid kui sisse logitud.
est.social on üks paljudest sõltumatutest Mastodoni serveritest, mida saab fediversumis osalemiseks kasutada.
est.social on mõeldud Eestis üldkasutatavaks Mastodoni serveriks. est.social is meant to be a general use Mastodon server for Estonia.

Administraator:

Serveri statistika:

90
aktiivsed kasutajad

est.social: TeaveProfiilikataloogIsikuandmete kaitse

Mastodon: TeaveTõmba äppKiirklahvidLähtekoodv4.3.6+est

#kubernetes

31 postitusega28 osalejaga3 postitust täna
Avalik
Rachel

New Blog Post:

wherein I detail a relatively simple deployment to the new cluster
https://blog.transitory.social/posts/2025-03-30-episode-iv-a-new-blog/

The ep IV ref is due to a mix of: a time skip, the forth actual post on there, sudden relevance of evil empires #Homelab #Kubernetes #SelfHosted #Blog

Transitory Blog2025-03-30 Epsisode IV: A New BlogIt is a period of civil war. Rebel spaceships, striking from a hidden base, have won their first victory against the evil Galactic Empire. Ok this feels rather topical all of a sudden.1 It has certainly been a while Shortly after my last post on here, I started up a post on deploying Sharkey. However, before I finished that post, really wanted to get my VPN link nailed down. However I ran into some issues and it didn’t end up working how I intended, and I left it in a mostly-working state, but this basically kicked the blogging out of focus.
Vastatud lõimes
Avalik
Scott Williams 🐧

The fact that there isn't just one #Kubernetes distro, one filesystem, one package manager, one container runtime, all under the control of one company is a *feature* and not a bug. Aggressive vendor lock-in strategies* just don't work as well. Users having a choice to migrate and to get help from other users to migrate if a vendor doesn't work out is a *good thing*. If someone gets too greedy or shuts down the shop, we can migrate or fork and carry on.

*Android being a clear exception here.

Avalik
Ariel (🐿 arc)

CoreDNS + Kubernetes question:

CoreDNS, in its stock configuration, assumes/uses the default service created for the Kubernetes API.

However, this gets a ClusterIP from the cluster's Service IP range as part of normal IPAM.

This IP is not known to the operating system or during cluster setup, so isn't in the IP SANs for the TLS certificate. This causes CoreDNS to error out trusting the Kubernetes API when trying to watch services.

The the default Kubernetes service is roughly well-known as it's the bottom of the service IP range + 1 but that still feels... odd.

I looked into automatic in-cluster certificate management and rotation but that seems more about Kubelet client certificates for the API server, and none of the actual TLS certificates. Which kinda makes sense cause otherwise cyclic dependencies.

kubernetes.io/docs/tasks/admin

KubernetesCustomizing DNS ServiceThis page explains how to configure your DNS Pod(s) and customize the DNS resolution process in your cluster. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:
#Kubernetes#k8s#CoreDNS
Avalik *
Florian Haas

If you had a need for a hosted/managed #Kubernetes platform (meaning, all you get is API access and a kubeconfig, anything underneath you don't need to care about), and you or your company are based in Europe, where would you go?

Ideally I'm looking for first-hand experience here; I am already aware of various sites merely cataloguing such services.

In particular, I am also interested in whether the service comes with a registry for your own container images.

(Boosts and comments welcome.)

Jätkatud lõim
Avalik
Marcel Waldvogel

9️⃣ Generating Multi-Architecture Docker Images Made Easy (2020-05)
#Docker (and therefore #Kubernetes) images are a versatile, high-level way of providing service and application abstraction. To some extent, it is platform-independent. However, it is not automatically processor-independent. Creating multi-architecture docker images is easier than what you think; using them is trivial (i.e., automatic).

Here my experiences for adding that to a few projects:
netfuture.ch/2020/05/multi-arc

Netfuture: The future is networked · Generating Multi-Architecture Docker Images Made EasyDocker is cool and portable, but distributing Dockerfiles comes at a disadvantage: The demands on the build environment are high. Distributing Docker images solves this, but building them for an architecture other than your CPU architecture seems complicated. Here is a simple solution.
AvastaLaiv lõimed
Teave