Skip to content

Latest commit

 

History

History
159 lines (135 loc) · 9.37 KB

cs_limitations.md

File metadata and controls

159 lines (135 loc) · 9.37 KB
Raw
copyright lastupdated keywords subcollection
years
2014, 2019
2019-11-26
kubernetes, iks, infrastructure, rbac, policy
containers

{:new_window: target="blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:note: .note} {:important: .important} {:deprecated: .deprecated} {:download: .download} {:preview: .preview}

Service limitations

{: #limitations}

{{site.data.keyword.containerlong}} and the Kubernetes open source project come with default service settings and limitations to ensure security, convenience, and basic functionality. Some of the limitations you might be able to change where noted. {: shortdesc}

If you anticipate reaching any of the following {{site.data.keyword.containerlong_notm}} limitations, contact the IBM team in the internal External link icon or external Slack External link icon. {: tip}

Service limitations

{: #tech_limits}

{{site.data.keyword.containerlong_notm}} comes with the following service limitations that apply to all clusters, independent of what infrastructure provider you plan to use. {: shortdesc}

In addition to the service limitations, make sure to also review the limitations for classic or VPC clusters. {: note}

{{site.data.keyword.containerlong_notm}} limitations
Category Description
API rate limits 100 requests per 10 seconds to the {{site.data.keyword.containerlong_notm}} API for each unique source IP address.
Worker node host access For security, you cannot SSH into the worker node compute host.
Kubernetes pod logs To check the logs for individual app pods, you can use the terminal to run `kubectl logs `. Do not use the Kubernetes dashboard to stream logs for your pods, which might cause a disruption in your access to the Kubernetes dashboard.

Classic cluster limitations

{: #classic_limits}

Classic infrastructure clusters in {{site.data.keyword.containerlong_notm}} are released with the following limitations. {: shortdesc}

Category Description
Compute
  • Worker nodes are available in [select flavors](/docs/containers?topic=containers-planning_worker_nodes#shared_dedicated_node) of compute resources.
  • You can have 900 worker nodes per cluster. If you plan to exceed 900 per cluster, contact the {{site.data.keyword.containerlong_notm}} team in the [internal ![External link icon](../icons/launch-glyph.svg "External link icon")](https://ibm-argonauts.slack.com/messages/C4S4NUCB1) or [external Slack ![External link icon](../icons/launch-glyph.svg "External link icon")](https://ibm-container-service.slack.com) first. If you see an IBM Cloud infrastructure capacity limit on the number of instances per data center or that are ordered each month, contact your IBM Cloud infrastructure representative.
  • You can run 110 pods per worker node. If you have worker nodes that run Kubernetes 1.13.7_1527, 1.14.3_1524, or later, and are provisioned with 11 CPU cores or more, you can support 10 pods per core, up to a limit of 250 pods per worker node. The number of pods includes `kube-system` and `ibm-system` pods that run on the worker node. For improved performance, consider limiting the number of pods that you run per compute core so that you do not overuse the worker node. For example, on a worker node with a `b3c.4x16` flavor, you might run 10 pods per core that use no more than 75% of the worker node total capacity.
Load balancing for apps
  • You can have 65,000 IPs per cluster in the 172.21.0.0/16 range that you can assign to Kubernetes services within the cluster.
  • The Ingress application load balancer (ALB) can process 32,768 connections per second.
Storage You can have a total of 250 IBM Cloud infrastructure file and block storage volumes per account. If you mount more than this amount, you might see an "out of capacity" message when you provision persistent volumes and need to contact your IBM Cloud infrastructure representative. For more FAQs, see the [file](/docs/infrastructure/FileStorage?topic=FileStorage-file-storage-faqs#how-many-volumes-can-i-provision-) and [block](/docs/infrastructure/BlockStorage?topic=BlockStorage-block-storage-faqs#how-many-instances-can-share-the-use-of-a-block-storage-volume-) storage docs.

VPC cluster limitations

{: #vpc_ks_limits}

VPC Generation 1 compute clusters in {{site.data.keyword.containerlong_notm}} are released with the following limitations. {: shortdesc}

Category Description
Compute
  • You can have up to 100 worker nodes across all VPC clusters per account.
  • Only certain flavors are available for worker node virtual machines.
  • Bare metal machines are not supported.
  • You cannot update or reload worker nodes. Instead, you can delete the worker node and rebalance the worker pool with the ibmcloud ks worker replace command.
Container platforms VPC clusters are available for only community Kubernetes clusters, not OpenShift clusters.
Load balancing for apps See [Exposing apps with VPC load balancers: Limitations](/docs/containers?topic=containers-vpc-lbaas#lbaas_limitations).
Location VPC clusters are available in the following [multizone metro locations](/docs/containers?topic=containers-regions-and-zones#zones): Dallas, Frankfurt, London, Sydney, and Tokyo.
Security groups You cannot use [VPC security groups](/docs/infrastructure/security-groups?topic=security-groups-about-ibm-security-groups#about-ibm-security-groups) to control traffic for your cluster. VPC security groups are applied to the network interface of a single virtual server to filter traffic at the hypervisor level. However, the worker nodes of your VPC cluster exist in a service account and are not listed in the VPC infrastructure dashboard. You cannot attach a security group to your worker nodes instances.
Storage
  • You can set up VPC Block Storage and {{site.data.keyword.cos_full_notm}} only.
  • VPC Block Storage is available as a cluster add-on. For more information, see [Storing data on VPC Block Storage](/docs/containers?topic=containers-vpc-block). Make sure to [attach a public gateway to all the VPC subnets](/docs/vpc-on-classic?topic=vpc-on-classic-creating-a-vpc-using-the-ibm-cloud-cli#step-5-attach-a-public-gateway) that the cluster uses so that you can provision VPC Block Storage.
  • {{site.data.keyword.cos_full_notm}} is available as a Helm chart. For more information, see [Storing data on {{site.data.keyword.cos_full_notm}}](/docs/openshift?topic=openshift-object_storage).
  • File storage and Portworx software-defined storage (SDS) are not available.
strongSwan VPN service Only [outbound VPN connections from the cluster](/docs/containers?topic=containers-vpn#strongswan_3) can be established. Additionally, because VPC clusters do not support UDP load balancers, the following config.yaml options are not supported for use in strongSwan Helm charts in VPC clusters:
  • enableServiceSourceIP
  • loadBalancerIP
  • zoneLoadBalancer
  • connectUsingLoadBalancerIP
Versions VPC clusters must run Kubernetes version 1.15 or later.
Virtual Private Cloud See [Known limitations](/docs/vpc-on-classic?topic=vpc-on-classic-known-limitations).
v2 API VPC clusters use the [{{site.data.keyword.containerlong_notm}} v2 API](/docs/containers?topic=containers-cs_api_install#api_about). The v2 API is currently under development, with only a limited number of API operations currently available. You can run certain v1 API operations against the VPC cluster, such as `GET /v1/clusters` or `ibmcloud ks cluster ls`, but not all the information that a Classic cluster has is returned or you might experience unexpected results. For supported VPC v2 operations, see the [CLI reference topic for VPC commands](/docs/containers?topic=containers-cli-plugin-kubernetes-service-cli#cli_classic_vpc_about).