copyright | lastupdated | ||
---|---|---|---|
|
2018-11-13 |
{: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}
Learn about cluster management responsibilities and terms and conditions that you have when you use {{site.data.keyword.containerlong}}. {:shortdesc}
{: #responsibilities}
Review the responsibilities that you share with IBM to manage your clusters. {:shortdesc}
IBM is responsible for:
- Deploying the master, worker nodes, and management components within the cluster, such as Ingress application load balancer, at cluster creation time
- Providing the security updates, monitoring, isolation, and recovery of the Kubernetes master for the cluster
- Monitoring the health of the worker nodes and providing automation for the update and recovery of those worker nodes
- Performing automation tasks against your infrastructure account, including adding worker nodes, removing worker nodes, and creating a default subnet
- Managing, updating, and recovering operational components within the cluster, such as the Ingress application load balancer and the storage plug-in
- Provisioning of storage volumes when requested by persistent volume claims
- Providing security settings on all worker nodes
You are responsible for:
- Configuring the {{site.data.keyword.containerlong_notm}} API key with the appropriate permissions to access the IBM Cloud infrastructure (SoftLayer) portfolio and other {{site.data.keyword.Bluemix_notm}} services
- Deploying and managing Kubernetes resources, such as pods, services, and deployments, within the cluster
- Leveraging the capabilities of the service and Kubernetes to ensure high availability of apps
- Adding or removing cluster capacity by resizing your worker pools
- Enabling VLAN spanning and keeping your multizone worker pools balanced across zones
- Creating public and private VLANs in IBM Cloud infrastructure (SoftLayer) for network isolation of your cluster
- Ensuring that all worker nodes have network connectivity to the Kubernetes master URL
If a worker node has both public and private VLANs, then network connectivity is configured. If worker nodes are set up with a private VLAN only, you must configure an alternative solution for network connectivity. For more information, see Planning private-only cluster networking.
- Updating the master kube-apiserver when Kubernetes version updates are available
- Keeping the worker nodes up-to-date on major, minor, and patch versions
- Recovering troubled worker nodes by running
kubectl
commands, such ascordon
ordrain
, and by runningibmcloud ks
commands, such asreboot
,reload
, ordelete
- Adding or removing subnets in IBM Cloud infrastructure (SoftLayer) as needed
- Backing up and restoring data in persistent storage in IBM Cloud infrastructure (SoftLayer)
- Setting up logging and monitoring services to support your cluster's health and performance
- Configuring health monitoring for worker nodes with Autorecovery
- Auditing events that change resources in your cluster, such as by using {{site.data.keyword.cloudaccesstrailfull}} to view user-initiated activities that change the state of your {{site.data.keyword.containerlong_notm}} instance
{: #terms}
Clients cannot misuse {{site.data.keyword.containerlong_notm}}. {:shortdesc}
Misuse includes:
- Any illegal activity
- Distribution or execution of malware
- Harming {{site.data.keyword.containerlong_notm}} or interfering with anyone's use of {{site.data.keyword.containerlong_notm}}
- Harming or interfering with anyone's use of any other service or system
- Unauthorized access to any service or system
- Unauthorized modification of any service or system
- Violation of the rights of others
See Cloud Services terms for overall terms of use.