README

这是一个从Kubernetes的Swagger定义逆向工程得到的完整PHP客户端。

您可以使用PHP来控制您的Kubernetes集群，以编程方式。

Kubernetes版本兼容性

支持的Kubernetes版本

由于此客户端是从Kubernetes的swagger文件生成的，因此它遵循Kubernetes的任何向后兼容性。您应该使用与您的集群对应的正确版本。

一个例外，关于兼容性，kpc支持等效的Kubernetes次要版本号。次要版本是版本号中的第二个数字。kpc版本1.8.0的次要版本为8。编号遵循语义版本规范，MAJOR.MINOR.PATCH。

例如，kpc 1.8.0不支持Kubernetes 1.9.2，但kpc 1.9.0支持Kubernetes 1.9.2和之前的Kubernetes版本。只有当kpc次要版本与Kubernetes次要版本匹配时，kpc才正式支持Kubernetes版本。kpc不会阻止用户使用不匹配的K8s版本，但Kubernetes版本始终要求kpc安装特定版本的组件，如docker，这些组件针对特定的Kubernetes版本进行了测试。

kpc不一定遵循Kubernetes发布中的PATCH编号。每个次要版本都是针对Kubernetes最新次要版本生成的。

兼容性矩阵

对于Kubernetes的所有版本，使用kpc的最新版本，但要注意，Kubernetes的更高版本不是kpc的官方支持。

kpc发布计划

此项目在每晚自动构建针对最新Kubernetes版本。如果您发现某个特定版本不可用，请创建一个问题，以便我可以手动生成它。

安装

通过使用[Composer] (https://getcomposer.org.cn/)包管理器，将kubernetes/php-client添加到您的项目composer.json中的依赖项。

{
    "require-dev": {
        "kubernetes/php-client": "~{KUBERNETES_VERSION}"
    }
}

KUBERNETES_VERSION应至少匹配您的Kubernetes集群的次要版本。

例如，使用"kubernetes/php-client": "~1.8"针对Kubernetes版本1.8.x

使用说明

现在您需要通过静态方法配置认证凭据（您只需要这样做一次）。

<?php

require_once('./vendor/autoload.php');

use KubernetesRuntime\Client;
use Kubernetes\API\ConfigMap as ConfigMapAPI;
use Kubernetes\Model\Io\K8s\Api\Core\V1\ConfigMap;

$master         = 'https://you-kubernetes-cluster.com';
$authentication = [
    'caCert' => '/usr/local/your-ca-file-location',
    'token'  => 'base64-based-token'
];

// This configure function only need to run once in the whole session
Client::configure($master, $authentication);

$ConfigMapAPI = new ConfigMapAPI();

$ConfigMap = new ConfigMap([
    'metadata' => [
        'name' => 'kubernetes-php-client-test'
    ],
    'data' => [
        'bar' => 'foo'
    ]
]);

$ConfigMapAPI->create('default',$ConfigMap);

$response = $ConfigMapAPI->read('default','kubernetes-php-client-test');

print_r($response);

/*
Kubernetes\Model\Io\K8s\Api\Core\V1\ConfigMap Object
(
    [apiVersion] => v1
    [data] => Array
        (
            [bar] => foo
        )

    [kind] => ConfigMap
    [metadata] => Kubernetes\Model\Io\K8s\Apimachinery\Pkg\Apis\Meta\V1\ObjectMeta Object
        (
            [annotations] => 
            [clusterName] => 
            [creationTimestamp] => 2018-08-07T10:32:06Z
            [deletionGracePeriodSeconds] => 
            [deletionTimestamp] => 
            [finalizers] => 
            [generateName] => 
            [generation] => 
            [initializers] => 
            [labels] => 
            [name] => kubernetes-php-client-test
            [namespace] => default
            [ownerReferences] => 
            [resourceVersion] => 24374466
            [selfLink] => /api/v1/namespaces/default/configmaps/kubernetes-php-client-test
            [uid] => 21f7036f-9a2d-11e8-89e9-0eeed2d5ffa8
            [isRawObject:protected] => 
            [rawData:protected] => 
        )

    [isRawObject:protected] => 
    [rawData:protected] => 
)

 */

认证

如文档所述，您可以使用满足您需求的任何认证模式。

$authentication支持以下配置

• caCert
• clientCert
• clientKey
• token
• username
• password

如果您需要修改客户端以满足您的Kubernetes集群需求，请参阅Guzzle的文档以传递您可能在$authentication数组中需要的任何额外配置参数。

类命名约定

Kubernetes是用GoLang编写的，因此它的swagger字段遵循Go命名约定。

模型

io.k8s.api.batch.v1beta1.CronJob将被转换为Kubernetes\Model\Io\K8s\Api\Batch\V1beta1\CronJob

API

根据swagger定义，每个API端点是独立条目。幸运的是，Kubernetes提供了额外信息，因此我们可以将它们分组，更多信息请参阅Kubernetes API

/apis/batch/v1beta1/cronjobs 可在 Kubernetes\API\CronJob 中找到

预GA版本功能

如所示，CronJob目前处于 v1beta1 状态。当你创建一个 Kubernetes\Model\Io\K8s\Api\Batch\V1beta1\CronJob() 对象时，它可能稍后会被移动到 Kubernetes\Model\Io\K8s\Api\Batch\V1\CronJob()。这是一个很好的方式，这样你就可以始终知道应该使用哪个版本。

此外，按照Kubernetes约定，如果你已经升级了集群，当CronJob API期望一个 v1 CronJob，但你还没有将代码升级到匹配的版本，将会触发PHP错误

PHP Fatal error:  Uncaught TypeError: Argument 2 passed to Kubernetes\API\CronJob::create() must be an instance of 
Kubernetes\Model\Io\K8s\Api\Batch\V1\CronJob, instance of Kubernetes\Model\Io\K8s\Api\Batch\V1beta1\CronJob 
given,

API实现

此API包装器实现了Kubernetes当前提供的所有API端点，有关如何使用它的完整文档，请参阅 API

Patch操作

如Kubernetes文档 中所述，Patch接受三种不同类型的操作

1. JSON Patch，Content-Type: application/json-patch+json
2. Merge Patch，Content-Type: application/merge-patch+json
3. Strategic Merge Patch，Content-Type: application/strategic-merge-patch+json

为了定义要使用哪种操作，开发者需要自己指定Content-Type。

为了在不修改Patch模型类的情况下实现API操作，你可以将patchOperation作为附加数据传递到模型中，可接受选项包括

1. patch
2. merge-patch
3. strategic-merge-patch

示例

$Patch = new \Kubernetes\Model\Io\K8s\Apimachinery\Pkg\Apis\Meta\V1\Patch([
    'patchOperation' => 'merge-patch',
    'spec' => [
        'template' => [
            'spec' => [
                'containers' => [[
                    'name' => 'nginx-ingress-controller',
                    'image' => 'quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.23.0'
                ]]
            ]
        ]
    ]
]);

$DeploymentAPI = new \Kubernetes\API\Deployment();
$DeploymentAPI->patch('default','nginx-ingress', $Patch);
 

上述请求将发送json到你的服务器

{
    "spec": {
        "template": {
            "spec": {
                "containers":[{
                    "name": "nginx-ingress-controller",
                    "image": "quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.23.0" 
                }]
            }
        }
    }
}

请注意，'patchOperation'字段将从请求中删除，并且Content-Type头将设置为merge-patch+json