Skip to main content

17 posts tagged with "k8s"

View All Tags

· 2 min read
Róbert Vašek

Summer, an ideal time to grow some containers! At Clyso, we are using Gardener extensively, with Clyso Linux by Garden Linux as base images for nodes and containers.

Composing an image

Clyso Linux is based on Debian Testing. The distribution’s repositories provide a curated set of base packages and can be installed and managed with the usual apt and dpkg utilities.

$ podman run --rm -it ghcr.io/gardenlinux/gardenlinux:1604.0 sh -c 'apt update && apt list | wc -l'
...
1994
$ podman run --rm -it debian:testing-20240812-slim sh -c 'apt update && apt list | wc -l'
...
66400

By comparison, Garden's repositories are much smaller than Debian's, and it is often necessary to add extra repositories when installing packages:

echo 'deb http://deb.debian.org/debian testing main' > /etc/apt/sources.list.d/debian.list
apt update

See gardenlinux/builder#31 issue for details about repository changes.

Building an image

The easiest and most idiomatic way to build a Clyso Linux based container image is to write a Dockerfile and use docker/podman/buildah or similar. See available gardenlinux base images.

Another way is to use gardenlinux/builder build tool. See Getting started docs on how to set up a build project and its features. Features then entirely replace the Dockerfile, as all build steps are specified there. To finally build the image, run:

feature='<Feature name>'
out_dir="<Path where to store build artifacts>/${feature}"
# Build the image. We are in the gardenlinux base directory.
TYPE=container build --target "${out_dir}" "${feature}"
# Now we just need to import the .tar OCI archive. For this example we are assuming amd64 arch.
podman import "${out_dir}/container-${feature}"-amd64-*-local.tar my-image

Note that the resulting image consists only of a single layer and is therefore not the best choice for normal use. Nevertheless, this is a handy way to test things before creating node images, which is the best use case of the tool.

Happy gardening!

· One min read
Joachim Kraftmayer

Today, Kubernetes is the first choice for running microservices in the public or private cloud. More and more developers and enterprises are building their applications on the modern microservice architecture.

Many of them are using Kubernetes for automated deployment of their workloads and want to benefit from the new flexibility and robustness. We are working on a solution for our customers to simplify and unify Day One and Day Two operations in their operations. With the increasing number of clusters, the management, updating and monitoring should be able to deal with it efficiently.

· One min read
Joachim Kraftmayer

Since 2018, we have been accompanying Rook.io in its development and had direct exchanges with various members of the project at Cephalocon in Beijing 2018 and Barcelona 2019.

In 2019, we began serving customers in production who use Rook.io to manage Ceph.

Storage Operators for Kubernetes

Rook transforms distributed storage systems into self-managing, self-scaling and self-healing storage services. It automates the tasks of a storage administrator: provisioning, bootstrapping, configuring, deploying, scaling, upgrading, migrating, disaster recovery, monitoring, and resource management. Rook leverages the power of the Kubernetes platform to deliver its services to any storage provider through a Kubernetes operator.

[https://rook.io/](https://rook.io/)

Since 2020, we are now working on improving the automated operation of Ceph with Rook.io. Furthermore, it is planned to have the platform fully audited by various certification bodies.

· One min read
Joachim Kraftmayer

After the acquisition of CoreOS by RedHat and the discontinuation of CoreOS support.

CoreOS Container Linux will reach its end of life on May 26, 2020 and will no longer receive updates.
(source: https://coreos.com/releases/)

We have decided together with our customer to provide an alternative to CoreOS before the 26.05.2020.

The current project name is Gardenlinux, although the name may not change until the public release.

Gardenlinux builds a full replacement for CoreOS based on Debian, without being biased by a target architecture.

Currently, the project supports the following platforms: BareMetal, AWS, GCP, Azure, VMWare, Openstack, and KVM and Docker.

Ports for AlibabaCloud are still under development.

In Produkton, Gardenlinux has already proven itself on BareMetal, KVM and AWS.

· One min read
Joachim Kraftmayer

Even though microservices with Kubernetes are gaining traction in the cloud environment, we still have a high demand to serve for managing virtual machines.

To keep the technology stack as lean as possible, we are phasing out our Cloud Controller environments and managing Virtual Machines using Kubernetes.

In a further step, we are thereby able to use Kubernetes to map complete environments with microservices and virtual machines through one technology.

· One min read
Joachim Kraftmayer

On behalf of the customer, we provided the optimal Kubernetes platform for ONAP as a managed service.

ONAP is a comprehensive platform for orchestration, management, and automation of network and edge computing services for network operators,

cloud providers, and enterprises. Real-time, policy-driven orchestration and automation of physical and virtual network functions enables rapid automation of new services and complete lifecycle management critical for 5G and next-generation networks.

· One min read
Joachim Kraftmayer

For a client, we are developing a unified interface/service to manage Virtual Machines and Containers for the Private Cloud with Kubernetes, Openstack, CloudStack, Opennebula, VMWare vSphere and Hyperscalers, such as GCP, AWS and Azure.

We are currently focusing on the following advantages:

  • Centralised management of distributed resources
  • Evaluation of costs across different providers
  • Reconciliation and implementation of planning
  • Mitigation of cloud provider failures
  • Connection of egde computing
  • Connection of sites