Kubernetes does not follow a monolithic approach, but consists of different components that can be put together in many different ways. The control of the system has the so-called Control Plane which typically operated on dedicated servers, the so-called master nodes. The Control Plane itself is divided into different components. These include: the kube-apiserver, the kube-controller-manager, the scheduler and the cloud-controller-manager.<\/p>\n
Resources and states are persisted in an etcd database. The actual workloads are run on separate servers, the worker nodes. To control the workloads, a component called kubelet is run on each server. A component called kube-proxy is also used for service management. The architecture is designed to be as modular as possible using the REST architecture, so that individual parts can be replaced without much effort.<\/p>\n
Defined interfaces enable Kubernetes to address a multitude of different components. Standards such as the Container Storage Interface (CSI), the Container Network Interface (CNI) or the Container Runtime Interface (CRI) enable compatibility between components.<\/p>\n
Besides the flexibility of the components regarding configuration and distribution, Kubernetes can be extended very well. A wide range of options are available for this purpose. Examples are: Cloud Provider Plugins, Admission Webhooks, Authentication Webhooks, Custom Resource Definitions and Operators. This extensibility allows you to configure exactly the configuration you need, and gives you the freedom to choose from a variety of extensions and projects that fit your needs. Be it network functionality, persistent storage, container runtime or certificate management.<\/p>\n
In addition to the offerings of the various cloud providers, a number of tools are available to install your own Kubernetes cluster – be it in the cloud or on-premise. Among the best known representatives are tools like kubeadm, kops, kubespray and rancher. The latter offers additional functionality besides the installation.<\/p>\n
Due to our experience from various projects and intensive further education in all areas relevant for productive operation, we can support you with the conception, installation and also support of your Kubernetes clusters.<\/p>\n
In a workshop we would work out the requirements for the cluster together and present the corresponding possibilities as well as their advantages and disadvantages based on your infrastructure and your requirements.<\/p>\n
Subsequently, we work out a concept for cluster realization together and support you and your colleagues in this phase with training to ensure the best possible start in the new infrastructure.<\/p>\n
In order to make the operation as robust and automated as possible in the long term, we work together to develop a CI\/CD (Continous Integration \/ Delivery) strategy. This includes, for example, the creation of own container images and deployments in the Kubernetes cluster. Tools such as Docker, Buildah or Kaniko are used to build the images and Gitlab, Helm, Kustomize, Argo CD or similar for deployment. The exact selection of the tools is done according to your requirements and preferences.<\/p>\n
To control the deployment, existing infrastructure such as Jenkins (X), Gitlab or tectonic pipelines can be used. Of course you can also count on us for the implementation of this area.<\/p>\n
credativ does not only support “vanilla” Kubernetes, but offers services for distributions based on them such as okd or Rancher.<\/p>\n
Do you already have an existing cluster, are not satisfied with its performance, or have problems you need help with?<\/p>\n
credativ is happy to support you, whether with an on-site workshop, debugging, uncomplicated remote access, with a fixed support contract or on hourly billing.<\/p>\n
Here is an overview of our services in short form:<\/strong><\/p>\n Functionality Kubernetes does not follow a monolithic approach, but consists of different components that can be put together in many different ways. The control of the system has the so-called Control Plane which typically operated on dedicated servers, the so-called master nodes. The Control Plane itself is divided into different components. These include: the kube-apiserver, […]<\/p>\n","protected":false},"author":90,"featured_media":0,"parent":4135,"menu_order":97,"comment_status":"closed","ping_status":"closed","template":"tpl-portfolio.php","meta":{"_acf_changed":false,"_improvement_type_select":"improve_an_existing","_thumb_yes_seoaic":false,"_frame_yes_seoaic":false,"seoaic_generate_description":"","seoaic_improve_instructions_prompt":"","seoaic_rollback_content_improvement":"","seoaic_idea_thumbnail_generator":"","thumbnail_generated":false,"thumbnail_generate_prompt":"","seoaic_article_description":"","footnotes":""},"class_list":["post-4751","page","type-page","status-publish","hentry"],"acf":[],"yoast_head":"\n\n