Download the PHP package kubernetes/php-client without Composer
On this page you can find all versions of the php package kubernetes/php-client. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package php-client
Kubernetes-PHP-Client (kpc)
This is a full PHP client reverse engineered from Kubernetes' Swagger defination.
You can control your Kubernetes cluster in PHP, the programmatical way.
Kubernetes Release Compatibility
Kubernetes Version Support
Since this client is generated from Kubernetes' swagger file, it follows whatever the backward compatibilities Kubernetes has. You should use the correct version against your cluster.
One exception, in regards to compatibility, kpc supports the equivalent Kubernetes minor release number. A minor
version is the second digit in the release number. kpc version 1.8.0 has a minor version of 8. The numbering follows
the semantic versioning specification, MAJOR.MINOR.PATCH.
For example, kpc 1.8.0 does not support Kubernetes 1.9.2, but kpc 1.9.0 supports Kubernetes 1.9.2 and previous
Kubernetes versions. Only when kpc minor version matches, the Kubernetes minor version does kpc officially support
the Kubernetes release. kpc does not stop a user from using mismatching versions of K8s, but Kubernetes releases
always require kpc to install specific versions of components like docker, that tested against the particular
Kubernetes version.
kpc does not neccessarily follow the PATCH number of Kubernetes release. Each minor version is generated against
latest minor version of Kubernetes lease.
Compatibility Matrix
| kpc version | k8s 1.7.x | k8s 1.8.x | k8s 1.9.x | k8s 1.10.x | k8s 1.11.x |
|---|---|---|---|---|---|
| 1.11.x | Y | Y | Y | Y | Y |
| 1.10.x | Y | Y | Y | Y | N |
| 1.9.x | Y | Y | Y | N | N |
| 1.8.x | Y | Y | N | N | N |
Use the latest version of kpc for all releases of Kubernetes, with the caveat that higher versions of Kubernetes are not officially supported by kpc.
kpc Release Schedule
This project runs on an automatic nightly build against latest Kubernetes release. If you found a particular version not available please open an issue so I can generate it manually.
Installation
Add a dependency on kubernetes/php-client to your project's composer.json by utilizing the [Composer]
(https://getcomposer.org/) package manager.
{KUBERNETES_VERSION} should match at least the minor version of your Kubernetes cluster.
For example "kubernetes/php-client": "~1.8" should be used against Kubernetes version 1.8.x
Usage instruction
Now you need to configure authentication credentials via a static method, (you only need to do this once).
Authentication
As per discribed in the documentation, you can use whatever authentication mode suits your requirement.
$authentication supports following configurations:
- caCert
- clientCert
- clientKey
- token
- username
- password
Should you need to modify your Client to meet your Kubernetes cluster requirement, please refer to Guzzle's
documentation to pass any extra configuration parameters
you might need in the $authentication array.
Class naming convention
Kubernetes is written in GoLang, hence its swagger field follows Go naming convention.
Models
io.k8s.api.batch.v1beta1.CronJob will be converted to Kubernetes\Model\Io\K8s\Api\Batch\V1beta1\CronJob
APIs
As per swagger definitions, each api endpoint is an independent entry. Luckily Kubernetes provided extra info so we can put them into groups, you can find more info in Kubernetes API
/apis/batch/v1beta1/cronjobs can be found in Kubernetes\API\CronJob
Pre-GA release features
As shown CronJob is currently in v1beta1 status. When you create a
Kubernetes\Model\Io\K8s\Api\Batch\V1beta1\CronJob() object, it may later be moved
Kubernetes\Model\Io\K8s\Api\Batch\V1\CronJob(). This is a good way so you would always know which version you
should be using.
Also, by following the Kubernetes conventions, if you have upgraded your cluster, when CronJob api expects a v1
CronJob, but you haven't upgraded your code to match the version, a PHP error will be prompted:
API Implementations
This API Wrapper implements all API endpoints currently provided by Kubernetes, for full documentation on how to use it please refere to API
Patch Operation
As specified in the Kubernetes document ,
Patch accepts three different kinds of operations:
- JSON Patch,
Content-Type: application/json-patch+json - Merge Patch,
Content-Type: application/merge-patch+json - Strategic Merge Patch,
Content-Type: application/strategic-merge-patch+json
To define which operation to use, developer is supposed to specifying the Content-Type by themselves.
In order implement the API operation without modifying the Patch model class, you can pass patchOperation as
additional data passed into the model, acceptable options are:
- patch
- merge-patch
- strategic-merge-patch
Example:
The above request will send a json to your server:
Be noted that the 'patchOperation' field is removed from the request, and the Content-Type header will be set as merge-patch+json
