Container Services
To enable IT organizations to meet dynamic requirements for implementing their business model, many companies are adopting modern IT platforms and organizational concepts such as DevOps. The following services support customers in optimally aligning application development and scalable IT operations with business dynamics.
With "Container Services," ix.Cloud offers a comprehensive tool set to deploy microservices in a fully automated manner and manage them efficiently. You focus entirely on your applications and processes, while Inventx operates the infrastructure for you and continuously develops it further.
| Service Name | Service Short Description |
|---|---|
| IT Baseline Protection | Explanation of Container Service IT Baseline Protection |
| Container Registry | Store and manage your Docker container images securely in ix.Cloud |
| Agile Factory | Offers a customer-customizable DevOps environment based on Openshift Kubernetes |
| AnyCloudK8s | Is a flexible and agnostic container platform service |
| Container Namespace | Allows developers to group selected types together during programming and outsource frequently needed code into modules |
IT Baseline Protection
This section describes general IT baseline protection for Container Services. If there are deviations for a specific service, these will be explicitly listed in the corresponding service scope.
Upgrade and Patching
-
Vendor-dependent requirements: Patching and upgrades are performed according to the requirements of the respective vendors. The intervals depend on when new versions or patches are released.
-
No handling of exclusions: Since this is a PaaS environment, no individual patches are distributed. All patches and upgrades are always performed at the platform level.
-
Emergency Patching: When a critical vulnerability is identified, it is patched immediately or upgraded as soon as a corresponding solution is provided by the vendor for the platform level.
Logging
- System logs: System logs are stored in Splunk.
- Retention period: Logs are retained for a period of 3 months.
Container Registry
The Container Registry is a central location where container images can be deployed. During deployment, the image is automatically subjected to a vulnerability scan. This allows the execution of insecure images to be prevented.
By integrating the Container Registry into existing CI/CD structures, fully automated pipelines can be set up.
Service Architecture
Service Scope
| Features | |
|---|---|
| IT-Grundschutz | ◼ |
| Quota | ◼ |
| Vulnerability Scan | ◼ |
| Robot Account | ◼ |
| Allow Public Access | ◼ |
| Access to User Interface | ◼ |
| CVE allowlist | ◼ |
IT-Grundschutz
Patching/Upgrade Interval
| Day of Week | Time |
|---|---|
| Once per quarter, on the second Wednesday of the month | 12:00-14:00 |
Hardening
- External Review: The service is reviewed by an external company every 2 years for security vulnerabilities and compliance.
- Assurance through CI/CD: The service is deployed via a pipeline (Continuous Integration/Continuous Deployment), which continuously ensures a secure and hardened setup.
Service Options
The following options are available in the "Container Registry" service and can be individually configured in self-service.
Quota
The quota defines the maximum storage capacity of the repository. Once this is reached, no further images can be uploaded.
The maximum storage capacity of the repository can be adjusted up or down at any time in the portal.
Vulnerability Scan
The Vulnerability Scan is enabled by default and cannot be disabled. All images are automatically checked daily by the Vulnerability Scanner. This ensures that a current vulnerability report is available for each image.
The following table lists and describes the available vulnerability scanners:
| Scanner | Description |
|---|---|
| Trivy | Simple scanning tool for applications that are not business-critical, or when working with less complex distributed architectures. |
| Aqua Enterprise | Advanced scanning tool for increased security. Particularly recommended for business-critical and complex cloud-native applications. |
The "Aqua Enterprise" Vulnerability Scanner generates additional costs.
Robot Account
Robot Accounts are generally used for workflow, deployment, and test automation.
If the value "-1" is entered in the "Expiration time in days" field, the token has no expiration date.
Allow Public Access
To authorize anonymous users with read access to a Container Registry, "Allow Public Access" must be enabled.
Access to User Interface
For advanced management of the Container Registry, access to the User Interface is provided. You can also view additional information via the UI, such as the Vulnerability Report of individual images.
CVE allowlist
An allow list can be created per repo/project, which applies to all images in this location. The validity period of the list can be defined with a date, or it can never expire. The default value is "Never expires".
Agile Factory
Agile Factory is a container platform service consisting of a variety of components that are interconnected to form an efficient and industry-optimized DevOps environment. All components and the connections between them are provided and operated by Inventx according to best practices, although individual components can also be provided by the customer.
With this service, cloud-native applications are created, managed, and scaled efficiently and simply. Inventx manages all components and provides relief for the customer. Developers can focus entirely on business logic and custom developments.
Agile Factory is offered in three standardized architectures/configurations (Basic, Top, and Premium) based on the Virtual Machine Service. The Basic configuration is recommended for non-production, the Top configuration for production, and the Premium configuration for business-critical applications.
The initial installation and configuration as well as any subsequent changes must be commissioned with a "Generic Request" or a "Service Request".
The Agile Factory service is based on the ix.Cloud standard Service Level, and the Worker Nodes of the respective configurations Basic, Top, and Premium define the applicable SLA.
For the restart of Agile Factory, an additional uplift of 2 hours must be expected in addition to the standard Service Level.
Service Architecture
Service Scope
| Feature | Basic | Top | Premium |
|---|---|---|---|
| IT Baseline Protection | ◼ | ◼ | ◼ |
| Initial Setup | ◻ | ◻ | ◻ |
| Git Repository | ◻ | ◻ | ◻ |
| Container Registry | ◻ | ◻ | ◻ |
| Container Network | ◼ | ◼ | ◼ |
| Management Node (Master & ETCD) | ◼ | ◼ | ◼ |
| Worker Node | ◼ | ◼ | ◼ |
| Persistent Storage | ◼ | ◼ | ◼ |
| Load Balancer | ◼ | ◼ | ◼ |
| Web Application Firewall | ◻ | ◻ | ◻ |
| Server Proxy | ◻ | ◻ | ◻ |
| Kubernetes Cluster Management | ◼ | ◼ | ◼ |
| Communication Management | ◼ | ◼ | ◼ |
| Permission Management | ◼ | ◼ | ◼ |
| Monitoring (logs & metrics) | ◼ | ◼ | ◼ |
| Cluster Network Interface | - | - | ◼ |
IT Baseline Protection
Patching/Upgrade Interval
| Day of Week | Time |
|---|---|
| Friday after the second Monday of the month | 02:00-06:00 |
Hardening
- The specifications were reviewed and approved in the ATSB
- These are implemented through automation
- This is ensured through GitOps
Malware Protection
All container images are scanned in the Container Registry for security vulnerabilities and weaknesses.
Configuration Management
Asset management is ensured through GitOps
Configuration Management
Asset management is ensured through GitOps
Service Options
The following describes the individual components of Agile Factory in detail. Some components are mandatory and some optional.
Initial Setup
The initial configuration of Agile Factory is implemented and billed as part of a project. Customer-specific configurations are specified in collaboration and then implemented.
Git Repository
For version control of deployment code, a Git Repository is mandatory in Agile Factory. This can be provided by the customer or by Inventx.
If the Git Repository is provided by Inventx, the customer receives an authorized user in Inventx's own Git, with which projects can be created, managed, and deleted. If the Git Repository is provided by the customer, the communication between the components is established and ensured in the Initial Setup.
Container Registry
Agile Factory uses a Container Registry for all deployments in the Kubernetes cluster. This component can be provided by the customer or by Inventx.
If Inventx provides the Container Registry, the Container Registry service is used. In this case, Inventx is responsible for trouble-free operation of this critical component.
If the Container Registry is provided by the customer, the communication between the two components Kubernetes Cluster and Container Registry is ensured in the Initial Setup. In this case, the customer is equally responsible for ensuring that communication between the components runs smoothly.
Container Network
Each Agile Factory requires a subnet. The size of the network determines how many Worker Nodes can be added to the cluster at most.
| Product | Options |
|---|---|
| Openshift/Rancher | The network size is freely selectable |
Management Node (Master & ETCD) for Openshift/Rancher
The Management Node is responsible for managing the Kubernetes cluster. Via the Management Node, the Kubernetes cluster and applications installed on it can be managed via CLI, GUI, or API. It serves as the control plane of the cluster and continuously manages the cluster's current state to the defined target state. The Management Node coordinates all tasks including scheduling and scaling of applications.
This cluster component is installed and configured according to Inventx best practices on dedicated Virtual Machine resources. To achieve fault tolerance, more than one Management Node is installed depending on the service configuration.
The initial configuration of a Management Node is fixed and defined as follows:
| Feature | Basic | Top | Premium |
|---|---|---|---|
| Number of Servers | Rancher: 1, OpenShift: 3 | Rancher: 3, OpenShift: 3 | Rancher: 3, OpenShift: 3 |
| Service Level | Rhodium | Rhodium | Rhodium |
| Hardware Profile | Rancher: P2/8, OpenShift: P4/32 | Rancher: P2/8, OpenShift: P4/32 | Rancher: P2/8, OpenShift: P4/32 |
| Storage Class | High Performance | High Performance | High Performance |
| Backup Retention Time | 14 days | 14 days | 14 days |
Worker Node
The Worker Node is a Virtual Machine on which applications are executed and which is controlled by the Management Node.
Unlike the Management Node, hardware resources for the Worker Node can be selected and adjusted. Either additional Worker Nodes are added to the Kubernetes cluster (scale-out) or the hardware profile of existing Worker Nodes is changed (scale-up).
Resource adjustment of Worker Nodes can be commissioned with a "Service Request".
The initial configuration and expansion steps per service configuration for Openshift/Rancher are shown in the following table:
| Feature | Basic | Top | Premium |
|---|---|---|---|
| Number of Servers 1* | 2 (initial) to 30 | 3 (initial) to 30 | 3 (initial) to 30 |
| Service Level | Silver | Gold | Rhodium |
| Hardware Profile 2* | P4/16 (initial) P8/32 P8/64 |
P4/16 (initial) P8/32 P8/64 |
P4/16 (initial) P8/32 P8/64 |
| Storage Class | Standard | Standard | Standard |
| Backup Retention Time | 14 days | 14 days | 14 days |
1* The more Worker Nodes the cluster has, the more spares (Worker Nodes) must be included.
- up to 16 Worker Nodes: 1 spare
- from 16 Worker Nodes: 2 spares
2* Further hardware profiles can be requested from Inventx.
Persistent Storage
For persistent data, Agile Factory is equipped with persistent storage (SVM) in the Initial Setup. If needed, the Kubernetes cluster can be expanded with additional persistent storage.
Typically, persistent storage is obtained from the File Storage service. Optionally, the Object Storage service can also be used as external persistent storage.
All storage classes are geo-redundant. The following storage classes are provided and can be used through application-specific configuration.
Snapshots are triggered when corresponding Kubernetes resources are created by the application. This makes it possible to create a consistent snapshot of application data.
| Feature | Description | Storage Classes | Reclaim Policy | Storage Classes (deprecated) |
|---|---|---|---|---|
| Block (Snapshot capable) | Creating snapshots is possible via kubeApi | block-std | Retain | netapp-block-std-ndr-$CUSTOMER-$ENV |
| Block Economy | No snapshot capabilities | block-eco | Retain | netapp-block-eco-ndr-$CUSTOMER-$ENV |
| File (Snapshot capable) | Creating snapshots is possible via kubeApi | file-std | Retain | netapp-file-std-ndr-$CUSTOMER-$ENV |
| File Economy | No snapshot capabilities | file-eco | Retain | netapp-file-eco-ndr-$CUSTOMER-$ENV |
Recommendations for Using Storage Classes
In general, the eco storage classes should be preferred.
| Storage Class | Description |
|---|---|
| Block | Storage class for all SAN workloads that require their own data protection, triggered by scheduler |
| Block Economy | Storage class for all SAN workloads that do not require their own data protection |
| File | Storage class for all NAS workloads that require their own data protection, triggered by scheduler |
| File Economy | Storage class for all NAS workloads that do not require their own data protection. This storage class is marked as default in the cluster |
Additional Storage Features
- When removing PVCs and PVs with the Reclaim Policy "Retain", the volume in the backend is deleted only after 14 days. Re-provisioning the volume must be ordered via Generic Request
- Autoscaling of PVCs using a File Storage Class is automatically expanded at a threshold of 79%. The expansion depends on the original size of the PVC. This usage check is performed every 5 minutes.
Load Balancer
To build resilient applications in the cluster, the use of a Layer 7 Load Balancer or a Web Application Firewall is mandatory.
Web Application Firewall
To build resilient applications in the cluster, the use of a Web Application Firewall or a Layer 7 Load Balancer is mandatory.
Compared to a Load Balancer, a Web Application Firewall provides additional protection against unwanted requests to applications.
Server Proxy
For applications to communicate to the Internet (outgoing traffic), the use of the Inventx Server Proxy is mandatory. See our Server Proxy service for details.
In the Initial Setup, it is defined whether a private or shared Server Proxy is used in the cluster.
Kubernetes Cluster Management
The Kubernetes clusters are centrally managed with one of the cluster management systems Openshift/Rancher or AnyCloudK8s. In the Initial Setup, the product to be used is defined with the customer.
Kubernetes Cluster Management essentially includes monthly patching and updating/upgrading of the entire platform as needed.
Communication Management
Inventx ensures that applications within the cluster cannot communicate with each other by default. Upon request, the customer can allow communication between applications with SSL encryption. SSL encryption is ensured through a self-signed certificate.
Permission Management
An individual RBAC concept can be implemented via the Authentication Authorization Infrastructure (AAI) and the LDAP Operator. For this purpose, customer-defined AD groups and Kubernetes cluster roles are linked together.
For Inventx to perform all configurations during Initial Setup, the customer must provide the following information:
- desired AD groups
- an AD read-only user
- key material for LDAPS
Monitoring (logs & metrics)
During operating hours, the Container Service is continuously monitored automatically by Inventx. Any events are logged, forwarded to the appropriate support organization, and processed during service hours.
For all Agile Factory components for which Inventx is responsible, logs are collected centrally, evaluated, and appropriate measures are taken by Inventx when problems are identified.
Logs are retained for 90 days.
AnyCloudK8s
AnyCloudK8s is a versatile, agnostic container platform service that consists of a variety of components. These components are optimally interconnected to provide an efficient and industry-specific DevOps environment. Inventx provides all components and their connections according to best practices and operates them. However, there is also the possibility that customers can provide individual components themselves.
With AnyCloudK8s, enterprises can efficiently create, manage, and scale cloud-native applications – simply and without complications. The platform offers maximum flexibility, regardless of which cloud provider you use.
Thanks to comprehensive management of all components by Inventx, customers are significantly relieved. Developers can focus entirely on business logic and custom developments without having to deal with infrastructure.
Additionally, AnyCloudK8s is available in the ix.Portal as a self-service – including easy provisioning and management of the environment directly via Portal.
Ordering can take some time, as network provisioning is not yet fully end-to-end automated. Once the network is available, the cluster will be automatically provisioned.
The AnyCloudK8s service is based on the ix.Cloud standard service level, and the Worker Nodes of the respective versions Silver and Rhodium determine the applicable SLA.
For the restart of AnyCloudK8s, an additional uplift of 1 hour must be expected beyond the standard service level.
Service Architecture
Service Scope
| Feature | Basic | Premium |
|---|---|---|
| IT Baseline Protection | ◼ | ◼ |
| Initial Setup | ◼ | ◼ |
| Git Repository | ◻ | ◻ |
| Container Registry | ◻ | ◻ |
| Container Network | ◼ | ◼ |
| Cluster Control Plane | ◼ | ◼ |
| Worker Pool | ◼ | ◼ |
| Worker Node | ◼ | ◼ |
| Persistent Storage | ◼ | ◼ |
| Load Balancer | ◼ | ◼ |
| Web Application Firewall | ◻ | ◻ |
| Server Proxy | ◼ | ◼ |
| Kubernetes Cluster Management | ◼ | ◼ |
| Communication Management | ◼ | ◼ |
| Permission Management | ◼ | ◼ |
| Monitoring (logs & metrics) | ◼ | ◼ |
| Cluster Network Interface | ◼ | ◼ |
IT Baseline Protection
Patching/Upgrade Interval
| Day of Week | Time |
|---|---|
| Friday after the second Monday of the month | 02:00-06:00 hours |
Hardening
- Requirements were reviewed and approved in the ATSB
- These are implemented through automation with GitOps
Malware Protection
All container images are scanned in the Container Registry for security vulnerabilities and weaknesses.
Configuration Management
Asset management is ensured through GitOps and CRs (ix.Cloud Operators)
Service Options
The individual components of AnyCloudK8s are described in detail below. Some components are mandatory and some are optional. This is evident in the table above AnyCloudK8s Service Scope.
Initial Setup
When ordering a new cluster, provisioning can take up to 5 days. The service is not yet fully automated, as the network is ordered separately from the responsible team as a managed service. Once the network is ready, the cluster is subsequently provisioned fully automatically.
After initial provisioning, all further service functions are fully automated, such as patching/updates and worker pool management (expanding, modifying, shrinking).
Git Repository
For versioning code of deployments, a Git repository is mandatory in AnyCloudK8s. This can be provided by the customer or by Inventx.
If the Git repository is provided by Inventx, the customer receives an authorized user in Inventx's own Git with which projects can be created, managed, and deleted. If the Git repository is provided by the customer, communication between the components is established and ensured during Initial Setup.
Container Registry
AnyCloudK8s uses a container registry for all deployments in the Kubernetes cluster. This component can be provided by the customer or by Inventx.
If Inventx provides the container registry, the Container Registry service is used. In this case, Inventx is responsible for trouble-free operation of this critical component.
If the container registry is provided by the customer, communication between the two components (Kubernetes cluster and container registry) is ensured during Initial Setup. In this case, the customer is equally responsible for ensuring that communication between the components runs without disruption.
Container Network
For the AnyCloudK8s environment, an additional subnet is needed. The size of the network determines how many worker nodes can be added to the cluster at most.
Please note that the entire IP range is not available for the worker nodes. Additional management and PaaS components are provisioned in this network, which are essential for service delivery. These components require their own IP resources, which restricts the usable area for the worker nodes accordingly.
Network sizes are predefined in three T-shirt sizes: small(/27), middle(/26), and large(/25)
| T-shirt Size | Maximum Worker Nodes |
|---|---|
| Small | 10 |
| Medium | 26 |
| Large | 58 |
Additionally, a DHCP VM is deployed, which manages IP addresses in the container network. This service is automatically provisioned and fully configured when the network for AnyCloudK8s is set up. This ensures that all components can communicate seamlessly with each other and network resources are managed efficiently.
The valid-lifetime = lease time is fixed at 3600 seconds.
Cluster Control Plane
The control plane is used to manage the Kubernetes cluster. Through it, the Kubernetes API can manage the cluster and applications installed on it. It serves as the control layer of the cluster and constantly manages the actual state of the cluster to the defined target state. The control plane coordinates all tasks, including scheduling and scaling of applications.
To ensure high fault tolerance and availability, the control plane is deployed on a seed Kubernetes cluster.
Required resources are dynamically ensured at the IaaS level.
| Feature | Basic | Premium |
|---|---|---|
| Seed Cluster | Local Redundancy | Geo-Redundancy |
| Service Level | Silver | Rhodium |
| Storage Class | High Performance | Standard |
| Backup Retention Time | 14 Days | 14 Days |
Worker Pool
A cluster can consist of one or more worker pools. For each worker pool, you define a uniform worker node (e.g., CPU/RAM profile) and can thus address different requirements within the same cluster.
When multiple worker pools make sense
Multiple worker pools are used to combine different worker nodes – such as general-purpose nodes and those with large amounts of memory – in one cluster and distribute workloads accordingly. Using taints and tolerations, you ensure that certain workloads only run on designated nodes.
Targeted placement via pod specification: Control scheduling via nodeSelector (or node affinity if needed) so that pods are scheduled to the appropriate worker pools and worker nodes.
Advanced Worker Pool Management
Worker pools can not only be created and expanded in the portal, but also specifically adjusted. This allows different worker nodes, hardware profiles, and scheduling requirements to be cleanly separated within a cluster and controlled throughout their lifecycle.
Advanced Management for Worker Pool Adjustments
With advanced features, you can adapt worker pools to current requirements without rebuilding the entire cluster:
-
Modify worker pools in detail Change pool-specific settings such as worker node/flavor, resource profile, metadata, and scheduling parameters. This allows you to tailor workloads to appropriate node profiles even after deployment.
-
Scale down worker pools Reduce the number of worker nodes in a pool in a controlled manner. Nodes are orderly removed from the pool to reduce capacity and optimize costs (e.g., after peak loads or after project completion).
-
Define taints/labels/annotations per worker pool Store rules and metadata directly on the worker pool:
- Labels for targeted scheduling (e.g., nodeSelector / Affinity)
- Taints to reserve pools for special workloads (e.g., GPU, high-memory) and only allow them via tolerations
- Annotations for additional control and integration information (e.g., operations, monitoring, automation)
Worker Node
The worker node is a Virtual Machine on which applications are executed and managed by the Management Node.
Unlike the Management Node, hardware resources can be selected and adjusted on the worker node. You can either add additional worker nodes to the Kubernetes cluster (scale-out) or change the hardware profile on existing worker nodes (scale-up).
An expansion can be performed independently through the Worker Pool.
| Standard | RAM in GB | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 4 | 8 | 16 | 24 | 32 | 64 | 96 | 128 | 256 | ||
Number of vCPU |
2 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ |
| 4 | ⁃ | ◼ | ◼ | ⁃ | ◼ | ◼ | ⁃ | ⁃ | ⁃ | |
| 6 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| 8 | ⁃ | ⁃ | ◼ | ⁃ | ◼ | ◼ | ⁃ | ◼ | ⁃ | |
| 12 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| 16 | ⁃ | ⁃ | ⁃ | ⁃ | ◼ | ◼ | ⁃ | ◼ | ◼ | |
| 24 | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | ⁃ | |
| System Disk | FlatCar: 80 GB | |||||||||
The difference to AgileFactory is that in AnyCloudK8s a worker node is first added to a cluster, so no additional spare nodes need to be provisioned. The expansion is automated in the backend and can be provisioned faster.
1* Further hardware profiles can be requested from Inventx.
Persistent Storage
For persistent data, AnyCloudK8s is equipped with persistent storage (SVM) during Initial Setup. Only one persistent storage can be provisioned per cluster in the subnet.
Typically, persistent storage is obtained from the File Storage service. Optionally, the Object Storage service can also be used as persistent storage from external sources.
With AnyCloudK8s, storage classes are automatically provisioned according to the cluster's SLA.
| Feature | Basic | Premium |
|---|---|---|
| Cluster | Local Redundancy | Geo-Redundancy |
| Persistent Storage | Local Redundancy | Geo-Redundancy |
The following storage classes are provided and can be used through application-specific configuration.
| Feature | Description | Storage Classes | Reclaim Policy |
|---|---|---|---|
| Block (Snapshot capable) | Creating snapshots is possible via kubeApi | block-std | Retain |
| Block Economy | No snapshot capabilities | block-eco | Retain |
| File (Snapshot capable) | Creating snapshots is possible via kubeApi | file-std | Retain |
| File Economy | No snapshot capabilities | file-eco | Retain |
Snapshots are triggered by the application when creating corresponding Kubernetes resources. This allows creating a consistent snapshot of application data.
Recommendations for Using Storage Classes
In general, the eco storage classes are preferable.
| Storage Class | Description |
|---|---|
| Block | Storage class for all SAN workloads that require their own data backup, triggered by scheduler |
| Block Economy | Storage class for all SAN workloads that do not require their own data backup |
| File | Storage class for all NAS workloads that require their own data backup, triggered by scheduler |
| File Economy (default) | Storage class for all NAS workloads that do not require their own data backup. This storage class is marked as default in the cluster |
Additional Storage Features
- When removing PVCs and PVs with the reclaim policy "Retain", the volume in the backend is deleted only after 14 days. Reprovisioning of the volume must be ordered via generic request
- Auto-scaling of PVCs using a file storage class is automatically expanded when a threshold of 79% is reached. The expansion depends on the original size of the PVC. This usage check is performed every 5 minutes.
Load Balancer
To build resilient applications in the cluster, the use of a Layer 4/7 Load Balancer or a Web Application Firewall is mandatory.
When provisioning an AnyCloudK8s cluster, no load balancer is automatically installed or configured. If a load balancer is needed, the customer defines it themselves in the cluster via manifest (e.g., as a service of type LoadBalancer, according to the provided template).
apiVersion: v1
kind: Service
metadata:
name: loadbalancer-sample
annotations:
lb.ixcloud.ch/enable: ""
lb.ixcloud.ch/retain: ""
lb.ixcloud.ch/fqdn: "only-test.[FQDN]"
lb.ixcloud.ch/loadBalancingAlgorithm: "LeastConnections"
lb.ixcloud.ch/maxThroughput: "10"
lb.ixcloud.ch/costCenter: "[Cost124]"
spec:
type: LoadBalancer
selector:
app: my-app # must match the pod labels
ports:
- name: http
port: 80
targetPort: 8080
protocol: TCP
Once the load balancer is defined in the cluster, our automation ensures that backend configuration is updated automatically upon changes (e.g., when adjusting an IP address or patching/upgrading).
Features
- Automated adjustments: Changes to backend configurations occur without manual intervention.
- Scalability: Multiple load balancers can be managed simultaneously per cluster to support more complex requirements.
This automation ensures efficient and error-free management of network components and simplifies scaling and expansion of cluster infrastructure.
Web Application Firewall
To build resilient applications in the cluster, the use of a Web Application Firewall or a Layer 7 Load Balancer is mandatory.
- Compared to a load balancer, a web application firewall provides additional protection against unwanted requests to applications.
- If an L7 load balancer or WAF is needed, first deploy an L4 load balancer via manifest in the cluster. Then it can be converted to L7 or WAF accordingly via a Generic Request.
Server Proxy
For applications within the AnyCloudK8s cluster to communicate with the internet (outbound traffic), the use of the Inventx server proxy is mandatory. For more details, see the documentation of our Server Proxy service.
When provisioning an AnyCloudK8s cluster, only the shared server proxy is used. This ensures that all outbound connections meet Inventx's security and compliance requirements.
Kubernetes Cluster Management
Kubernetes clusters from AnyCloudK8s are centrally managed by Inventx. A key feature of this approach is the decoupling of the control plane from the cluster. This gives the customer admin rights on the cluster, while Inventx ensures overall management.
Inventx regularly provides supported and current patches as well as new Kubernetes versions, which the customer can use for upgrades as needed. Announcements of new versions and deprecations of existing versions are made monthly via release notes according to the ixCloud process.
This management model ensures the security, stability, and currency of the Kubernetes environment, while the customer retains maximum flexibility for managing their cluster.
Communication Management
Inventx ensures that applications within the cluster cannot communicate with each other by default. Upon request, the customer can allow communication between applications with SSL encryption. SSL encryption is ensured through a self-signed certificate.
Permission Management
As described in Kubernetes Cluster Management, the customer receives admin rights for the provisioned cluster. These permissions enable the customer to have full control and flexibility in managing and using the cluster.
The corresponding kubeconfig can be easily downloaded via the portal. With this configuration file, admins can access the cluster directly via their preferred tools (e.g., kubectl).
Monitoring (logs & metrics)
During operating hours, Inventx continuously monitors the container service by machine. Any events are logged, forwarded to the appropriate support organization, and processed during service hours.
For all components of AnyCloudK8s for which Inventx is responsible, logs are centrally collected, evaluated, and appropriate measures are taken by Inventx when problems are detected.
Logs are retained for 90 days
When provisioning a cluster, a Time Series Database is automatically set up in the portal under the same subscription. The cluster's metrics are transferred to this data source.
The data source serves to store and analyze metrics, enabling continuous monitoring and optimization of the cluster.
This integration ensures that all relevant metrics are centrally collected and can be used for monitoring or reporting purposes as needed.
Cluster Network Interface
Clusters can be provisioned by default with the container network interface (CNI) Canal or Cilium.
Canal combines the functionalities of Flannel (for network overlay) and Calico (for network security policies) to provide a robust and flexible networking setup for Kubernetes clusters.
Cilium is based on eBPF and enables performant, scalable, and security-oriented network implementation. In addition to pod-to-pod connectivity, Cilium supports granular network policies and advanced observability features.
Container Namespace
The Container Namespace Service simplifies the use of Agile Factory and AnyCloudK8s. All required Clusterbase permissions for namespaces are provided in this service.
Namespaces are central in Kubernetes and a key element. Namespaces allow developers to build their projects modularly and outsource specific aspects to separate files. This enables them to modernize their applications and reduce complexity, allowing developers to focus on what is essential.
Service Architecture
Service Scope
| Feature | Rancher | OpenShift | AnyCloudK8s |
|---|---|---|---|
| Initial Setup | ◻ | ◻ | ◻ |
| Target Destination | ◼ | ◼ | ◼ |
| Network Policy | ◼ | ◼ | ◼ |
| Quotas | ◼ | ◼ | ◼ |
| KubeConfig | ◼ | ◼ | ◼ |
| Annotations/Labels | ◼ | ◼ | ◼ |
To ensure that system-critical namespaces remain protected, we have introduced a blacklist filter. This ensures that certain namespaces used by the cluster cannot be ordered. The following namespaces are affected:
openshift openshift- ; kube- ; trident ; argocd ; cert-manager ; patch-operator ; patch-automation ; conjur ; k8s-operators ; ix-ocpbackup-system ; ix-aai ; alertmanager-zabbix-webhook ; collectorforopenshift ; cerberus ; kyverno ; aqua
Service Options
The individual components of Container Namespace are described in detail below.
Initial Setup
The basis for using a Container Namespace is an existing Agile Factory or AnyCloudK8s. The subscription used for the order must be activated beforehand on the Target Destination.
For the release of available target destinations and all subsequent changes, a "Generic Request" must be submitted.
Target Destination
It is possible to define per subscription which target destinations can be used. This allows you to specifically define which users can deploy a Container Namespace or an application on which Agile Factory or AnyCloudK8s.
Network Policy
When creating a namespace on the target destination, predefined network policies are set. These must be adjusted when deploying the application according to the application's requirements.
List of network policies set by Inventx:
- Allow Namespace
- Allow DNS
- Default denyAll
Quotas
When creating a namespace, quotas must be defined. This creates the prerequisite that applications can be operated resiliently on the corresponding cluster. Quotas ensure that an application cannot exhaust all cluster resources and adversely affect other applications.
The following quotas must be specified when creating:
| Feature | Description |
|---|---|
| Memory | Memory quota in MB on the namespace |
| CPU | CPU quota in millicpu on the namespace |
| Storage | Storage in GB on the namespace |
| PVC | Maximum number of PVCs in the namespace |
All these quotas have a minimum value defined. The definitions can be seen in the table below:
There are applications that cannot work with the ResourceQuotas or Network Policy of the namespace. These can be disabled when ordering the namespace.
| Quota | Minimum Value |
|---|---|
| Memory | > 256MB |
| CPU | > 200m |
| Storage | >= 1 |
| PVC | >0 |
The maximum value is not limited, so it is at the customer's discretion to define this according to available resources on the Agile Factory or AnyCloudK8s.
The memory quota must be chosen carefully, as it can cause applications to crash if it is chosen too low.
KubeConfig
Each Container Namespace has a service account. This account can be ordered with different permissions. Either as an Admin Service Account or as a Viewer. In addition to the service account, a token is also created, which expires after the defined "Time to Live" period. The definition of whether the permission should be Admin or Viewer can only be set when creating the Container Namespace.
The KubeConfig can be displayed and copied. If the KubeConfig has expired (reached the Time to Live), it can be renewed. This ensures that the permission on the namespace does not always have the same credentials.
The Container Namespace can only be deleted on the target cluster if it was ordered with Admin rights.
Annotations/Labels
This feature enables the setting of labels and annotations when creating and managing namespaces, which promotes automation and transparency in the cluster.
Labels enable clear and structured categorization of namespaces, for example by team affiliation, environment, or application type. Annotations provide the ability to store additional metadata such as descriptions, responsibilities, or operational information.
The key of a label or annotation cannot be changed after creation. The associated value, however, can be adjusted at any time.