| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2019-10-01 |
kubernetes, iks, compliance, security standards, faq, kubernetes pricing, kubernetes service pricing, ibm cloud kubernetes service pricing, iks pricing, kubernetes charges, kubernetes service charges, ibm cloud kubernetes service charges, iks charges, kubernetes price, kubernetes service price, ibm cloud kubernetes service price, iks price, kubernetes billing, kubernetes service billing, ibm cloud kubernetes service billing, iks billing, kubernetes costs, kubernetes service costs, ibm cloud kubernetes service costs, iks costs |
containers |
{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:note: .note} {:download: .download} {:preview: .preview} {:faq: data-hd-content-type='faq'}
{: #faqs}
{: #kubernetes} {: faq}
Kubernetes is an open source platform for managing containerized workloads and services across multiple hosts, and offers managements tools for deploying, automating, monitoring, and scaling containerized apps with minimal to no manual intervention. All containers that make up your microservice are grouped into pods, a logical unit to ensure easy management and discovery. These pods run on compute hosts that are managed in a Kubernetes cluster that is portable, extensible, and self-healing in case of failures. {: shortdesc}
For more information about Kubernetes, see the Kubernetes documentation 
.
{: #kubernetes_service} {: faq}
With {{site.data.keyword.containerlong_notm}}, you can create your own Kubernetes cluster to deploy and manage containerized apps on {{site.data.keyword.cloud_notm}}. Your containerized apps are hosted on IBM Cloud infrastructure compute hosts that are called worker nodes. You can choose to provision your compute hosts as virtual machines with shared or dedicated resources, or as bare metal machines that can be optimized for GPU and software-defined storage (SDS) usage. Your worker nodes are controlled by a highly available Kubernetes master that is configured, monitored, and managed by IBM. You can use the {{site.data.keyword.containerlong_notm}} API or CLI to work with your cluster infrastructure resources and the Kubernetes API or CLI to manage your deployments and services.
For more information about how your cluster resources are set up, see the Service architecture. To find a list of capabilities and benefits, see Why {{site.data.keyword.containerlong_notm}}.
{: #faq_benefits} {: faq}
{{site.data.keyword.containerlong_notm}} is a managed Kubernetes offering that delivers powerful tools, an intuitive user experience, and built-in security for rapid delivery of apps that you can bind to cloud services that are related to {{site.data.keyword.ibmwatson}}, AI, IoT, DevOps, security, and data analytics. As a certified Kubernetes provider, {{site.data.keyword.containerlong_notm}} provides intelligent scheduling, self-healing, horizontal scaling, service discovery and load balancing, automated rollouts and rollbacks, and secret and configuration management. The service also has advanced capabilities around simplified cluster management, container security and isolation policies, the ability to design your own cluster, and integrated operational tools for consistency in deployment.
For a detailed overview of capabilities and benefits, see Why {{site.data.keyword.containerlong_notm}}.
{: #faq_free} {: faq}
You can have 1 free cluster at a time in {{site.data.keyword.containerlong_notm}}, and each free cluster expires in 30 days. Free clusters have select capabilities, minimal 2x4 compute resources, select single zone locations, and support only the Kubernetes container platform and {{site.data.keyword.cloud_notm}} classic infrastructure provider. Free clusters are ideal for testing out Kubernetes deployments and getting familiar with the {{site.data.keyword.containerlong_notm}} API, CLI, and console tools. After you are done playing around with your free cluster, you can copy your configuration files and redeploy them to a standard cluster.
To create a free cluster, you must have a Pay-As-You-Go or Subscription {{site.data.keyword.cloud_notm}} account. Free clusters cannot be created in Lite accounts. {: note}
{: #container_platforms} {: faq}
With {{site.data.keyword.containerlong_notm}}, you can select from two container management platforms: the IBM version of community Kubernetes and Red Hat OpenShift on IBM Cloud. The container platform that you select is installed on your cluster master and worker nodes. Later, you can update the version but cannot roll back to a previous version or switch to a different container platform. If you want to use multiple container platforms, create a separate cluster for each.
For more information, see Comparison between OpenShift and community Kubernetes clusters.
- Kubernetes
- [Kubernetes ](https://kubernetes.io/) is a production-grade, open source container orchestration platform that you can use to automate, scale, and manage your containerized apps that run on an Ubuntu operating system. With the [{{site.data.keyword.containerlong_notm}} version](/docs/containers?topic=containers-cs_versions#cs_versions), you get access to community Kubernetes API features that are considered **beta** or higher by the community. Kubernetes **alpha** features, which are subject to change, are generally not enabled by default. With Kubernetes, you can combine various resources such as secrets, deployments, and services to securely create and manage highly available, containerized apps.
To get started, [create a Kubernetes cluster](/docs/containers?topic=containers-cs_cluster_tutorial#cs_cluster_tutorial). - OpenShift
- Red Hat OpenShift on IBM Cloud is a Kubernetes-based platform that is designed especially to accelerate your containerized app delivery processes that run on a Red Hat Enterprise Linux 7 operating system. You can orchestrate and scale your existing OpenShift workloads across on-prem and off-prem clouds for a portable, hybrid solution that works the same in multicloud scenarios.
To get started, try out the [Red Hat OpenShift on IBM Cloud tutorial](/docs/openshift?topic=openshift-openshift_tutorial).
{: #managed_master_worker} {: faq}
Every Kubernetes cluster in {{site.data.keyword.containerlong_notm}} is controlled by a dedicated Kubernetes master that is managed by IBM in an IBM-owned {{site.data.keyword.cloud_notm}} infrastructure account. The Kubernetes master, including all the master components, compute, networking, and storage resources, is continuously monitored by IBM Site Reliability Engineers (SREs). The SREs apply the latest security standards, detect and remediate malicious activities, and work to ensure reliability and availability of {{site.data.keyword.containerlong_notm}}. Add-ons, such as Fluentd for logging, that are installed automatically when you provision the cluster are automatically updated by IBM. However, you can choose to disable automatic updates for some add-ons and manually update them separately from the master and worker nodes. For more information, see Updating cluster add-ons.
Periodically, Kubernetes releases major, minor, or patch updates. These updates can affect the Kubernetes API server version or other components in your Kubernetes master. IBM automatically updates the patch version, but you must update the master major and minor versions. For more information, see Updating the Kubernetes master.
Worker nodes in standard clusters are provisioned in to your {{site.data.keyword.cloud_notm}} infrastructure account. The worker nodes are dedicated to your account and you are responsible to request timely updates to the worker nodes to ensure that the worker node OS and {{site.data.keyword.containerlong_notm}} components apply the latest security updates and patches. Security updates and patches are made available by IBM Site Reliability Engineers (SREs) who continuously monitor the Linux image that is installed on your worker nodes to detect vulnerabilities and security compliance issues. For more information, see Updating worker nodes.
{: #faq_ha} {: faq}
The {{site.data.keyword.containerlong_notm}} architecture and infrastructure is designed to ensure reliability, low processing latency, and a maximum uptime of the service. By default, every cluster in {{site.data.keyword.containerlong_notm}} is set up with multiple Kubernetes master instances to ensure availability and accessibility of your cluster resources, even if one or more instances of your Kubernetes master are unavailable.
You can make your cluster even more highly available and protect your app from a downtime by spreading your workloads across multiple worker nodes in multiple zones of a region. This setup is called a multizone cluster and ensures that your app is accessible, even if a worker node or an entire zone is not available.
To protect against an entire region failure, create multiple clusters and spread them across {{site.data.keyword.containerlong_notm}} regions. By setting up a network load balancer (NLB) for your clusters, you can achieve cross-region load balancing and cross-region networking for your clusters.
If you have data that must be available, even if an outage occurs, make sure to store your data on persistent storage.
For more information about how to achieve high availability for your cluster, see High availability for {{site.data.keyword.containerlong_notm}}.
{: #secure_cluster} {: faq}
You can use built-in security features in {{site.data.keyword.containerlong_notm}} to protect the components in your cluster, your data, and app deployments to ensure security compliance and data integrity. Use these features to secure your Kubernetes API server, etcd data store, worker node, network, storage, images, and deployments against malicious attacks. You can also leverage built-in logging and monitoring tools to detect malicious attacks and suspicious usage patterns.
For more information about the components of your cluster and how you can secure each component, see Security for {{site.data.keyword.containerlong_notm}}.
{: #faq_access} {: faq}
{{site.data.keyword.containerlong_notm}} uses {{site.data.keyword.iamshort}} (IAM) to grant access to cluster resources through IAM platform roles and Kubernetes role-based access control (RBAC) policies through IAM service roles. For more information about types of access policies, see Pick the right access policy and role for your users. {: shortdesc}
The access policies that you assign users vary depending on what you want your users to be able to do. You can find more information about what roles authorize which types of actions on the User access reference page or in the following table's links. For steps to assign policies, see Granting users access to your cluster through {{site.data.keyword.cloud_notm}} IAM.
| Use case | Example roles and scope |
|---|---|
| App auditor | Viewer platform role for a cluster, region, or resource group, Reader service role for a cluster, region, or resource group. |
| App developers | Editor platform role for a cluster, Writer service role scoped to a namespace, Cloud Foundry developer space role. |
| Billing | Viewer platform role for a cluster, region, or resource group. |
| Create a cluster | Account-level permissions set by the API key with Super User infrastructure credentials for classic clusters, or the Administrator platform role to VPC Infrastructure for VPC on Classic clusters. Individual user permissions for Administrator platform role to {{site.data.keyword.containerlong_notm}}, and Administrator platform role to {{site.data.keyword.registrylong_notm}}. For more information, see Preparing to create clusters. |
| Cluster administrator | Administrator platform role for a cluster, Manager service role not scoped to a namespace (for the whole cluster). |
| DevOps operator | Operator platform role for a cluster, Writer service role not scoped to a namespace (for the whole cluster), Cloud Foundry developer space role. |
| Operator or site reliability engineer | Administrator platform role for a cluster, region, or resource group, Reader service role for a cluster or region or Manager service role for all cluster namespaces to be able to use kubectl top nodes,pods commands. |
| {: caption="Types of roles you might assign to meet different use cases." caption-side="top"} |
{: #faq_security_bulletins} {: faq}
If vulnerabilities are found in Kubernetes, Kubernetes releases CVEs in security bulletins to inform users and to describe the actions that users must take to remediate the vulnerability. Kubernetes security bulletins that affect {{site.data.keyword.containerlong_notm}} users or the {{site.data.keyword.cloud_notm}} platform are published in the {{site.data.keyword.cloud_notm}} security bulletin.
Some CVEs require the latest patch update for a Kubernetes version that you can install as part of the regular cluster update process in {{site.data.keyword.containerlong_notm}}. Make sure to apply security patches in time to protect your cluster from malicious attacks. For more information about what is included in a security patch, refer to the version changelog.
{: #bare_metal_gpu} {: faq}
Yes, you can provision your worker node as a single-tenant physical bare metal server. Bare metal servers come with high-performance benefits for workloads such as data, AI, and GPU. Additionally, all the hardware resources are dedicated to your workloads, so you don't have to worry about "noisy neighbors".
For more information about available bare metal flavors and how bare metal is different from virtual machines, see Physical machines (bare metal).
{: #supported_kube_versions} {: faq}
{{site.data.keyword.containerlong_notm}} concurrently supports multiple versions of Kubernetes. When a latest version (n) is released, versions up to 2 behind (n-2) are supported. Versions more than 2 behind the latest (n-3) are first deprecated and then unsupported. The following versions are currently supported:
Supported Kubernetes versions:
- Latest: 1.15.4
- Default: 1.14.7
- Other: 1.13.11
For more information about supported versions and update actions that you must take to move from one version to another, see Version information and update actions.
Have an OpenShift cluster? The supported OpenShift version is 3.11, which includes Kubernetes 1.11. {: note}
{: #supported_regions} {: faq}
{{site.data.keyword.containerlong_notm}} is available worldwide. You can create standard clusters in every supported {{site.data.keyword.containerlong_notm}} region. Free clusters are available only in select regions.
For more information about supported regions, see Locations.
{: #standards} {: faq}
{{site.data.keyword.containerlong_notm}} implements controls commensurate with the following standards:
- EU-US Privacy Shield and Swiss-US Privacy Shield Framework
- Health Insurance Portability and Accountability Act (HIPAA)
- Service Organization Control standards (SOC 1, SOC 2 Type 1)
- International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
- International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)
- Payment Card Industry Data Security Standard (PCI DSS)
{: #faq_integrations} {: faq}
You can add {{site.data.keyword.cloud_notm}} platform and infrastructure services as well as services from third-party vendors to your {{site.data.keyword.containerlong_notm}} cluster to enable automation, improve security, or enhance your monitoring and logging capabilities in the cluster.
For a list of supported services, see Integrating services.
{: #hybrid} {: faq}
You can connect services in {{site.data.keyword.cloud_notm}} Public with your on-prem data center to create your own hybrid cloud setup. Examples for how you can leverage {{site.data.keyword.cloud_notm}} Public and Private with apps that run in your on-prem data center include:
- You create a cluster with {{site.data.keyword.containerlong_notm}} in {{site.data.keyword.cloud_notm}} Public, but you want to connect your cluster with an on-prem database.
- You create a Kubernetes cluster in {{site.data.keyword.cloud_notm}} Private in your own data center and deploy apps to your cluster. However, your app might use an {{site.data.keyword.ibmwatson_notm}} service, such as Tone Analyzer, in {{site.data.keyword.cloud_notm}} Public.
To enable communication between services that run in {{site.data.keyword.cloud_notm}} Public and services that run on-prem, you must set up a VPN connection. To connect your {{site.data.keyword.cloud_notm}} Public or Dedicated environment with an {{site.data.keyword.cloud_notm}} Private environment, see Using {{site.data.keyword.containerlong_notm}} with {{site.data.keyword.cloud_notm}} Private.
For an overview of supported {{site.data.keyword.containerlong_notm}} offerings, see Comparison of offerings and their combinations.
{: #private} {: faq}
If you do not want to move your apps into {{site.data.keyword.cloud_notm}} Public but you still want to leverage the features of {{site.data.keyword.containerlong_notm}}, you can install {{site.data.keyword.cloud_notm}} Private. {{site.data.keyword.cloud_notm}} Private is an application platform that can be installed locally on your own machines and that you can use for developing and managing on-prem, containerized apps in your own controlled environment behind a firewall.
For more information, see the {{site.data.keyword.cloud_notm}} Private product documentation .
{: #pricing} {: faq}
To find detailed pricing information for the service, see {{site.data.keyword.containerlong_notm}}: Pricing . You can also review what components you are charged for when you use {{site.data.keyword.containerlong_notm}} or estimate your costs.
{: #charges} {: faq}
With {{site.data.keyword.containerlong_notm}} clusters, you can use IBM Cloud infrastructure compute, networking, and storage resources with platform services such as Watson AI or Compose Database-as-a-Service. Each resource might entail its own charges that can be fixed, metered, tiered, or reserved.
- Worker nodes
- Outbound networking
- Subnet IP addresses
- Storage
- {{site.data.keyword.cloud_notm}} services
- Red Hat OpenShift on IBM Cloud
- Worker nodes
Clusters can have two main types of worker nodes: virtual or physical (bare metal) machines. Flavor (machine type) availability and pricing varies by the zone that you deploy your cluster to.
Virtual machines feature greater flexibility, quicker provisioning times, and more automatic scalability features than bare metal, at a more cost-effective price than bare-metal. However, VMs have a performance trade-off when compared to bare metal specs, such as networking Gbps, RAM and memory thresholds, and storage options. Keep in mind these factors that impact your VM costs:
- Shared vs. dedicated: If you share the underlying hardware of the VM, the cost is lower than dedicated hardware, but the physical resources are not dedicated to your VM.VPC on Classic clusters are available only as **shared**.
- Hourly billing only: Hourly offers more flexibility to order and cancel VMs quickly.
- Tiered hours per month: Hourly billing is tiered. As your VM remains ordered for a tier of hours within a billing month, the hourly rate that you are charged lowers. The tiers of hours are as follows: 0 - 150 hours, 151 - 290 hours, 291 - 540 hours, and 541+ hours.
Physical machines, or bare metal, (not available for VPC on Classic clusters) yield high-performance benefits for workloads such as data, AI, and GPU. Additionally, all the hardware resources are dedicated to your workloads, so you don't have "noisy neighbors". Keep in mind these factors that impact your bare metal costs:
- Monthly billing only: All bare metals are charged monthly.
- Longer ordering process: After you order or cancel a bare metal server, the process is completed manually in your IBM Cloud infrastructure account. Therefore, it can take more than one business day to complete.
For more information about the machine specifications, see [Available hardware for worker nodes](/docs/containers?topic=containers-planning_worker_nodes#planning_worker_nodes).
- Public bandwidth
Bandwidth refers to the public data transfer of inbound and outbound network traffic, both to and from {{site.data.keyword.cloud_notm}} resources in data centers around the globe.
**Classic clusters**: Public bandwidth is charged per GB. You can review your current bandwidth summary by logging into the [{{site.data.keyword.cloud_notm}} console](https://cloud.ibm.com/), from the menu  selecting **Classic Infrastructure**, and then selecting the **Network > Bandwidth > Summary** page.
Review the following factors that impact public bandwidth charges:
- Location: As with worker nodes, charges vary depending on the zone that your resources are deployed in.
- Included bandwidth or Pay-As-You-Go: Your worker node machines might come with a certain allocation of outbound networking per month, such as 250 GB for VMs or 500 GB for bare metal. Or, the allocation might be Pay-As-You-Go, based on GB usage.
- Tiered packages: After you exceed any included bandwidth, you are charged according to a tiered usage scheme that varies by location. If you exceed a tier allotment, you might also be charged a standard data transfer fee.
For more information, see [Bandwidth packages ](https://www.ibm.com/cloud/bandwidth).
**VPC on Classic clusters**: For more information about how internet data transfer works in your Virtual Private Cloud, see [Pricing for VPC](/docs/vpc-on-classic?topic=vpc-on-classic-pricing-for-vpc)
- Subnet IP addresses
**Classic clusters**: When you create a standard cluster, a portable public subnet with 8 public IP addresses is ordered and charged to your account monthly.
If you already have available subnets in your infrastructure account, you can use these subnets instead. Create the cluster with the `--no-subnets` [flag](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cs_cluster_create), and then [reuse your subnets](/docs/containers?topic=containers-subnets#subnets_custom).
**VPC on Classic clusters**: For more information about charges for floating IPs and other networking costs, see [Pricing for VPC](/docs/vpc-on-classic?topic=vpc-on-classic-pricing-for-vpc)
- Storage
- When you provision storage, you can choose the storage type and storage class that is right for your use case. Charges vary depending on the type of storage, the location, and the specs of the storage instance. Some storage solutions, such as file and block storage offer hourly and monthly plans that you can choose from. To choose the right storage solution, see [Planning highly available persistent storage](/docs/containers?topic=containers-storage_planning#storage_planning).
For VPC on Classic, only block storage is available.
For more information, see:- [NFS file storage pricing](https://www.ibm.com/cloud/file-storage/pricing)
- [Block storage pricing](https://www.ibm.com/cloud/block-storage/pricing)
- [Object storage plans](https://www.ibm.com/cloud/object-storage/pricing/#s3api)
- {{site.data.keyword.cloud_notm}} services
- Each service that you integrate with your cluster has its own pricing model. Review each product documentation and use the {{site.data.keyword.cloud_notm}} console to [estimate costs](/docs/billing-usage?topic=billing-usage-cost#cost).
- Red Hat OpenShift on IBM Cloud
- If you create a [Red Hat OpenShift on IBM Cloud cluster](/docs/openshift?topic=openshift-openshift_tutorial), your worker nodes are installed with the Red Hat Enterprise Linux operating system, which increases the price of the [worker node machines](#nodes). An OpenShift license is also included, which incurs monthly costs in addition to the hourly VM costs or monthly bare metal costs. Each OpenShift cluster has an internal registry that includes a file storage volume to store the images in. For more information, see [What am I charged for when I use an OpenShift cluster?](/docs/openshift?topic=openshift-faqs#openshift_charges).
Monthly resources are billed based on the first of the month for usage in the preceding month. If you order a monthly resource in the middle of the month, you are charged a prorated amount for that month. However, if you cancel a resource in the middle of the month, you are still charged the full amount for the monthly resource. {: note}
{: #bill} {: faq}
When you use a billable {{site.data.keyword.cloud_notm}} account, platform and infrastructure resources are summarized in one bill. If you linked your {{site.data.keyword.cloud_notm}} and IBM Cloud infrastructure accounts, you receive a consolidated bill for your {{site.data.keyword.cloud_notm}} platform and infrastructure resources.
{: #cost_estimate} {: faq}
Yes, see Estimating your costs. Keep in mind that some charges are not reflected in the estimate, such as tiered pricing for increased hourly usage. For more information, see What am I charged for when I use {{site.data.keyword.containerlong_notm}}?.
{: #usage} {: faq}
You can check your current usage and estimated monthly totals for your {{site.data.keyword.cloud_notm}} platform and infrastructure resources. For more information, see Viewing your usage. To organize your billing, you can group your resources with resource groups.