Re: [kubernetes-users] What is the best way to deploy the Redis cluster

[Guang Ya Liu]

Thanks Rodrigo!

But even with deployment, I can still have volume mounts in the deployment
to mount to external storage, so even using deployment, I can still
have persistency,
right?

For statefulset, I can use volumeClaimTemplates to mount PVCs to have
persistency,
but how an it make upgrade easily? Also I can always rolling upgrade a
Deployment for this case, comments?

Thanks,

Guangya

On Thu, Jul 20, 2017 at 11:35 AM, Rodrigo Campos 
wrote:

> If you use redis without persistency, probably a deployment is fine.
>
> Stateful sets are newer, and might help you (didn't look at the yaml) to
> manage persistency in redis (and redis upgraded, etc.) More easily
>
>
> On Wednesday, July 19, 2017, Guangya Liu  wrote:
>
>> Hi,
>>
>> I found that there are two ways to deploy a Redis cluster, one is in
>> openshift, it is using statefulset https://github.com
>> /openshift/origin/blob/master/examples/statefulsets/redis/redis.yaml
>>
>> And another is in Kuberntes helm charts, it is using Deployment + Service
>> to deploy the Redis cluster https://github.com/kub
>> ernetes/charts/tree/master/stable/redis/templates
>>
>> Using statefulset can make sure the hostname of redis will never change
>> even after redis restart, and the application can always use hostname to
>> access redis.
>>
>> Using deployment and service can enable other applications using service
>> to access the redis, which also works even after the redis restart.
>>
>> Does there are any recommendations for which one is better, or this
>> depend on user scenarios?
>>
>> Thanks,
>>
>> Guangya
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] What is the best way to deploy the Redis cluster

[Guang Ya Liu]

+ Kubernetes dev, hope can get more comments/suggestions here.

Thanks,

Guangya

On Fri, Jul 21, 2017 at 8:42 AM, Guang Ya Liu <gyliu...@gmail.com> wrote:

> Thanks Rodrigo!
>
> But even with deployment, I can still have volume mounts in the deployment
> to mount to external storage, so even using deployment, I can still have 
> persistency,
> right?
>
> For statefulset, I can use volumeClaimTemplates to mount PVCs to have 
> persistency,
> but how an it make upgrade easily? Also I can always rolling upgrade a
> Deployment for this case, comments?
>
> Thanks,
>
> Guangya
>
> On Thu, Jul 20, 2017 at 11:35 AM, Rodrigo Campos <rodrig...@gmail.com>
> wrote:
>
>> If you use redis without persistency, probably a deployment is fine.
>>
>> Stateful sets are newer, and might help you (didn't look at the yaml) to
>> manage persistency in redis (and redis upgraded, etc.) More easily
>>
>>
>> On Wednesday, July 19, 2017, Guangya Liu <gyliu...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I found that there are two ways to deploy a Redis cluster, one is in
>>> openshift, it is using statefulset https://github.com
>>> /openshift/origin/blob/master/examples/statefulsets/redis/redis.yaml
>>>
>>> And another is in Kuberntes helm charts, it is using Deployment +
>>> Service to deploy the Redis cluster https://github.com/kub
>>> ernetes/charts/tree/master/stable/redis/templates
>>>
>>> Using statefulset can make sure the hostname of redis will never change
>>> even after redis restart, and the application can always use hostname to
>>> access redis.
>>>
>>> Using deployment and service can enable other applications using service
>>> to access the redis, which also works even after the redis restart.
>>>
>>> Does there are any recommendations for which one is better, or this
>>> depend on user scenarios?
>>>
>>> Thanks,
>>>
>>> Guangya
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Kubernetes user discussion and Q" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to kubernetes-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to kubernetes-users@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] Applying resource limit after pod startsup

[Guang Ya Liu]

You can use `kubectl edit ` to update, but this will cause the pod
restart.

On Tue, Jul 4, 2017 at 7:14 AM,  wrote:

> Hi all
>
> We have a situation where our pods need a load of cpu on startup only and
> it seems that the limits for CPU that we have specified in our deployment
> is throttling the pod on startup and causing it to take over 2 mins to
> start. If we removed the limits configured in our deployment then start up
> is in seconds.
>
> e.g this
>
> resources:
>   limits:
> cpu: 600m
> memory: 768Mi
>   requests:
> cpu: 600m
> memory: 768Mi
>
> is replace by this
>
> resources:
>   limits:
> cpu: 600m
> memory: 768Mi
>   requests:
> memory: 768Mi
>
> Means startup in under 6 seconds.
>
> Ideally we would like to be able to apply some sort of cpu limits after
> the pod has started. Does anyone know if this can be achieved?
>
> Thanks in advance
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Re: [kubernetes-users] How to use PodSecurityPolicy

[Guang Ya Liu]

How did you set up your cluster and what is the parameter for apiserver,
kubelet?

One suggestion is that you can first test with `local-up-cluster.sh` and
check what parameters are needed for those two services and compare with
your env to see what are losing.

I did some test days ago and it works well with steps
https://github.com/kubernetes/kubernetes/blob/master/examples/podsecuritypolicy/rbac/README.md

BTW: The following are parameters for both apiserver and kubelet in my env
which works well.

root 15009 12786  6 02:32 pts/000:01:04
/root/kubernetes/_output/local/bin/linux/amd64/hyperkube apiserver
--insecure-allow-any-token --authorization-mode=RBAC --allow-privileged
--runtime-config=extensions/v1beta1=true,extensions/v1beta1/podsecuritypolicy=true
--v=3 --vmodule= --cert-dir=/var/run/kubernetes
--client-ca-file=/var/run/kubernetes/client-ca.crt
--service-account-key-file=/tmp/kube-serviceaccount.key
--service-account-lookup=true
--admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PodSecurityPolicy,ResourceQuota,DefaultStorageClass,DefaultTolerationSeconds
--admission-control-config-file= --bind-address=0.0.0.0 --secure-port=6443
--tls-cert-file=/var/run/kubernetes/serving-kube-apiserver.crt
--tls-private-key-file=/var/run/kubernetes/serving-kube-apiserver.key
--tls-ca-file=/var/run/kubernetes/server-ca.crt
--insecure-bind-address=127.0.0.1 --insecure-port=8080
--storage-backend=etcd3 --etcd-servers=http://127.0.0.1:2379
--service-cluster-ip-range=10.0.0.0/24 --feature-gates=AllAlpha=false
--cloud-provider= --cloud-config=
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-client-ca-file=/var/run/kubernetes/request-header-ca.crt
--requestheader-allowed-names=system:auth-proxy
--proxy-client-cert-file=/var/run/kubernetes/client-auth-proxy.crt
--proxy-client-key-file=/var/run/kubernetes/client-auth-proxy.key
--cors-allowed-origins=/127.0.0.1(:[0-9]+)?$,/localhost(:[0-9]+)?$

root 15470 12786  0 02:33 pts/000:00:00 sudo -E
/root/kubernetes/_output/local/bin/linux/amd64/hyperkube kubelet
--allow-privileged --v=3 --vmodule= --chaos-chance=0.0
--container-runtime=docker --rkt-path= --rkt-stage1-image=
--hostname-override=127.0.0.1 --cloud-provider= --cloud-config=
--address=127.0.0.1 --require-kubeconfig --kubeconfig
/var/run/kubernetes/kubelet.kubeconfig --feature-gates=AllAlpha=false
--cpu-cfs-quota=true --enable-controller-attach-detach=true
--cgroups-per-qos=true --cgroup-driver=cgroupfs
--keep-terminated-pod-volumes=true
--eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%
--eviction-soft= --eviction-pressure-transition-period=1m
--pod-manifest-path=/var/run/kubernetes/static-pods --cluster-dns=10.0.0.10
--cluster-domain=cluster.local --port=10250

Thanks,

Guangya



On Fri, Jul 7, 2017 at 11:23 AM, lin liqang 
wrote:

> Hi,
>
> I have followed the example https://github.com/kubernetes/
> kubernetes/tree/master/examples/podsecuritypolicy/rbac to use
> PodSecurityPolicy. But it seems not working in my env. Restricted
> users/group/serviceaccount still can launch privileged Pod.
>
> apiVersion: extensions/v1beta1
> kind: PodSecurityPolicy
> metadata:
>   name: privileged
> spec:
>   fsGroup:
> rule: RunAsAny
>   privileged: true
>   runAsUser:
> rule: RunAsAny
>   seLinux:
> rule: RunAsAny
>   supplementalGroups:
> rule: RunAsAny
>   volumes:
>   - '*'
> ---
> apiVersion: extensions/v1beta1
> kind: PodSecurityPolicy
> metadata:
>   name: restricted
> spec:
>   privileged: false
>   fsGroup:
> rule: RunAsAny
>   runAsUser:
> rule: MustRunAsNonRoot
>   seLinux:
> rule: RunAsAny
>   supplementalGroups:
> rule: RunAsAny
>   volumes:
>   - 'emptyDir'
>   - 'secret'
>   - 'downwardAPI'
>   - 'configMap'
>   - 'persistentVolumeClaim'
>   - 'projected'
>
>
> # privilegedPSP gives the privilegedPSP role
> # to the group privileged.
> apiVersion: rbac.authorization.k8s.io/v1beta1
> kind: ClusterRoleBinding
> metadata:
> name: privileged-psp-users
> subjects:
> - kind: Group
>   apiGroup: rbac.authorization.k8s.io
>   name: privileged-psp-users
> roleRef:
>apiGroup: rbac.authorization.k8s.io
>kind: ClusterRole
>name: privileged-psp-user
> ---
> # restrictedPSP grants the restrictedPSP role to
> # the groups restricted and privileged.
> apiVersion: rbac.authorization.k8s.io/v1beta1
> kind: ClusterRoleBinding
> metadata:
> name: restricted-psp-users
> subjects:
> - kind: Group
>   apiGroup: rbac.authorization.k8s.io
>   name: restricted-psp-users
> - kind: Group
>   apiGroup: rbac.authorization.k8s.io
>   name: privileged-psp-users
> - kind: ServiceAccount
>   name: default
>   namespace: restricted-psp-users
> - kind: User
>   name: restricted
>   apiGroup: rbac.authorization.k8s.io
> roleRef:
>apiGroup: rbac.authorization.k8s.io
>kind: 

Re: [kubernetes-users] Weighted load balancing to service/pods

[Guang Ya Liu]

I think the istio  can help you for such case, checkout
here https://istio.io/docs/concepts/traffic-management/request-routing.html
for detail, hope this helps!

On Sat, Aug 5, 2017 at 9:36 PM, 'Tim Hockin' via Kubernetes user discussion
and Q  wrote:

> As far as I know, nobody has implemented this, but it should be pretty
> trivial to write your own controller to manipulate labels based on your own
> definition of availability.
>
>
> On Aug 5, 2017 4:35 PM, "Rodrigo Campos"  wrote:
>
> I **guess** there is not: https://github.com/kubern
> etes/kubernetes/issues/25485
>
> Maybe with some other ingress back end (doubt it). Also, don't think this
> can be achieved with service either :-(
>
> So, I don't see any other way than istio, that issue I posted or deploy an
> nginx with that config. But maybe I'm missing something.
>
>
> On Saturday, August 5, 2017,  wrote:
>
>> I have a service that points to 2 independent pods running separate
>> scrape jobs against the same targets.  So their data will be similar but
>> different.  They run independently for redundancy reasons.  Right now a
>> service points to both and exposes the stats. The only problem is that
>> people will see different results based on which pod they end up landing
>> on.  In the traditional datacenter setup, I'd set the load balancer with
>> one pod to have a weight of 100 so it gets all of the traffic, and the only
>> time the second server would get traffic would be hit is if the initial
>> target ended up becoming unavailable.  This would be ideal for my
>> situation, so is there a way to implement that with k8s?  The front end
>> system can only point to one target, which is why I'd like the service (or
>> whatever construction does what I described) to do this.  I guess I can add
>> a routing layer with servers to do this, but I was hoping for a native
>> option if such a thing exists.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-users@googlegroups.com.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.